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@ Method and means for sharing I/O resources by a plurality of operating systems. 



@ Provides a method for increasing the connec- 
tivity of I/O resources to a multiplicity of operating 
systems (OSs) running in different resource parti- 
tions of a computer electronic complex (CEC) to 
okytain sharing of the I/O resources among the OSs 
of the CEC. including channels, subchannels 
(devices), and control units (CDs). The invention 
provMes image Identifiers (llDs) for assigning re- 
sources to the different OSs. Each shared I/O re- 



source has a sharing set of control blocks (CBs) in 
which a respective CB is assigned to (and located 
by) a respective I ID of one of the OSs. Each of the 
CBs in a sharing set provides a different image of 
the same I/O resource. The different CB images are 
independently set to different states by I/O oper- 
ations for the different OSs. so that the OSs can 
independently share the same I/O resource. 



Rank XsrcM (UK) Business Services 
(3. 10/3.6/3.3. i» 

PAGE 9190 * RCVO AT 9/1»2009 11:30:03 AM [^ast«m Daylight Tbnel * SVR:U8PT0-EFXRF-en4 * DNI8:2738300 • CSID:(413) 053-2743 * DURATION (mm-8S):41-4e 



9/18/2005 9:36 AM (413) 6S3-2743 Huffman Patent Group, LLC TO: 1-571-273-8300 PAGE: 006 OF 060 



EP 0 574 691 A1 



FIG. 1 



LOGICAL 
RESOURCE 
PARTITION- 1 
110=1 
FOR (OSl) 


! MS-I 


RESOURCES 1 




INCLUDE: , 




J NUMBER * 




OF CPUs 1 




ANO 1 




SYSTEM 




MEMORY 1 
■ 




LOGICAL 
RESOURCE 
PARTITION-N 
1ID=N 
FOR (05N) 


j MS-N 



HSA 

(HARDWARE 
STORAGE 
AREA) 



cec 



I/O 

CHANNEL SUBSYSTEM 




.PHYSICAL 
CHANNEL 
LINK I . 



PHYSICAL 
CHANNEL 
LINK S _ 



2 



PAOE 8(60 • RCVD AT 9/18/2009 1 1 :3«:03 AM [Eastem Daylight TImel • 8VR:U8PTMFXRF-en4 • DNI8:2738300 • C8ID:(41^ 093-2743 ' DURATION (inm^s):41-40 



9/18/2005 9:36 AM FROM: (413) 653-2743 Huffman Patent Group, LLC TO: 1-571-273-8300 PAGE; 007 OF 060 



EP 0 574 691 A1 



The entire contents of the following USA patent 
apprtcations, filed on the same day as the subject 
application, are incorporated by reference into thi« 
specification: application serial number 07/888,623 
(PO9-92-026), entitled **Channel path measure- 
ments for the multiple Image facility" by Stuckl et 
^; application serial number 07/888,977 (P09-92- 
028). entitled "Extensions to CHSC Commands to 
support the multiple image facility" by John et al; 
application serial number 07/898.875 (PO9-92-029), 
entitled "Pass-through for I/O channel subsystem 
call instructions for accessing shared resources in 
a computer system having a plurality of operating 
systems- by Brice et al. 

Also the following prior-filed applications as- 
signed to the same assignee as the subject ap- 
plication have their entire content Incorporated by 
reference into this specification: Application Serial 
Number 07/444,190. filed November 28, 1989» by 
C, J. Bailey et al. entitled "Method And Apparatus 
For Dynamically Managing I/O Connectivity" 
(Docket Number K1 98901 3): Application Serial 
Number 07/754,813, filed September 4, 1991, by 
R. Cwiakala et al. entitled •'Estat>lishing Synchro- 
nization Of Hardware And Software I/O Configura- 
tion Definitions" (Docket Number PO99103e): Ap- 
plication Serial Number 07/876.603. filed March 28, 
1991, by S. M. Bertson et al, entitled ''Method And 
Apparatus For Dynamic Changes To System I/O 
Configuration" (Docket Number PO990026); Appli- 
cation Serial Number 07/755^46, filed September 
5, 1991. by J. E. Bostick et a), entitled "Method 
And Apparatus For Dynamically Changing The 
Configuration Of A Logically Partitioned Data Pro- 
cessing System" (Docket number P0^1028); Ap- 
plication Serial Number 07/693,997, filed March 28, 
1991. by R. Cwiakala et al. entitled "Dynamically 
Changing A System I/O Configuration Definition" 
(Docket Number PO991012): Application Serial 
Number 07/860.797 filed March 30. 1992 by J. A. 
Frey et al, entitled "Management of Data Objects 
Used to Maintain State Infomnation for Shared Data 
Objects" (Docket Number PO992004); and Applica- 
tion Serial Numk)er 07/860.648. filed March 30, 
1992 by D. A. Elko et al, entitled "Message Path 
Mechanism tor Managing Connections Between 
Processors and a Coupling Facility" (Docket Num- 
ber PO992006). 

Introduction 

This invention provides a method that greatly 
increases the effective number of I/O channels, 
devices and control unit Images available to each 
of a plurality of operating systems (OSs) running 
on a CEC (computer electronic complex) without 
increasing the actual number of physical L^O re- 
sources. The Invention enables the OSs to directly 



share physical I/O resources without intervention 
from a hypervisor. 

Background 

5 

In the prior art, either only physical I/O channel 
resources or only I/O device resources, but not 
both, were directly sharable by operating systems 
(OSs) executing in different logical resource parti- 

w tions of a CEC (computer electronic complex) sys- 
tem. The OSs in a CEC are coordinated by a 
hypervisor. in which the processor and memory 
resources of the CEC have been divided among 
the separately executing OSs. The hypervisor may 

15 be structured in internal code (e.g. microcode) or in 
software. An example of an internal code type of 
hypervisor is the IBM PR/SM (processor 
resource/system manager), whteh coordinates re- 
source contentions among independently executing 

20 OSs In separate logical resource partitions. An ex- 
ample of a software hypervisor is the IBM S/370 
VM/MPQ (virtual machine/multiple prefenred 
guests) system, in which so-called virtual machines 
(called prefenred guests) execute separate OSs in 

25 respective logical resource partitions divided by the 
system software in a software directory. 

In prior systems, an I/O channel could be di- 
rectly shared only by assigning each OS which 
shared the channel a mutually exclusive subset of 

30 I/O devices which could be accessed via that chan- 
nel. When this technique was used, a single sub- 
channel existed to represent each I/O device, and 
this sutK^hannel was assigned to the OS which was 
assigned the corresponding device. Because it is 

^5 often desired to have I/O devices shared by. plural 
OSs, this technique was very limiting. 

In prior systems, an I/O device could t>e di- 
rectly shared only by assigning each OS which 
shared the device a mutually exclusive sutDset of 

40 I/O channels which couM be used to access that 
device. When this technique was used, a plurality 
of subchannels existed to represertt each I'O de- 
vice, and one of these subchannels were assigned 
to each OS which shared the device. Each sub- 

46 channel representing the same device was iden- 
tified by a different subchannel number. Because 
each I/O channel was assigned to a single OS with 
this technique, the number of channels needed 
would usually increase with the number OSs which 

50 were to share I/O devices. This commonly pre- 
sented a problem since the quantity of channels 
was limited to 256 due to the 8-bit number which 
was used to identify them. The quantity of sub- 
channels was less of a problem since the quantity 

66 of subchannels had a higher limit of 65538 due to 
the 16-bit number which was used to Identify them. 

It was possible in prior systems to share, but 
not directly share. tx)th I/O devices and the I/O 
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channels used to access these devices. However, 
this involved a large amount of ineffictem system 
overhead due to the need to intercept to the hyper- 
visor code for each I/O operation in order that the 
hypervisor could coordinate resource contentions. 
While the hypervisor code was executing on behalf 
of the OS, the OS was suspended. 

In practice, the overhead of using the hyper- 
visor to obtain sharing of both I/O devices and the 
I/O channels used to access these devices was so 
inefficient that most often the choice was made to 
directly share either only I/O channels or only I/O 
devices. This allowed all 1/0 operations for the OS 
to be performed without hypervisor involvement. 
This direct use of I/O resources by an OS is called 
'*l/0 passthru* because these I/O operations 
"passthru** (i.e. bypass) the hypervisor. 

In the prior art a System/380 (S/390) CEO has 
an I/O channel subsystem having one or more I/O 
processors (lOPs) to control a plurality of I/O chan- 
nel processors (CHPRs) in the CEC for controlling 
a like number of channels, which may be fiber 
optic channels or parallel wire channels connecting 
to I/O control units with I/O devices. These are the 
channels involved in the previously discussed 
hypervisor and OS control A widely used type of 
fiber optic channel uses the IBM ESCON architec- 
ture. The CEC consists of one or more central 
processors (CPUs), system memory, arKi the I/O 
subsystem. All of these parts of a CBC are in- 
cluded in the CEC resources used by programs 
executing in the CEC. 

A control unit is the conduit for the exchange of 
information between an I/O device and a channel. 
Similarly a channel is the operating system's con- 
duit for the exchange of information between main 
storage and an I/O device. 

An IBM publicatton (form number SA22-7202) 
published October 1980 entitled "ES Architecture 
390 ESCON I/O Interface* describes the then exist- 
ffig ESCON channel/control unit path connections. 

The various resources in the CEC are divided 
among the OSs by using a plurality of directories 
or state descriptors (SDs) in system memory that 
respectively assign the CEC resources to the OSs 
executing in the respective resource partitions. The 
CEC hypervisor may be allocated Its own logical 
resource partition to control the overall operation of 
the CEC, including the dispatching of OSs on the 
central processors (CPUs) In the CEC, and resolv- 
ing conflicts among the OSs. Each OS controls the 
dispatching of application programs running uncfer 
the respective OS. usually without hypervisor in- 
volvement (unless an exception occurs). 

Early hypervisor systems required the hyper- 
visor to control all I/O operations for all OSs in the 
CEC (e.g. early VM/370), including having the 
hypervisor assign all channel operations, start all 
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subchannels for all 1/0 devices in the CEC, and 
handle all I/O interruptions from the devices for all 
programs running under the OSs. 

USA patent 4,843.541 (PO9-87-002) entitled 

s "Logical Resource Partitioning of a Data Process- 
ing System*, assigned to the same assignee as the 
subject application, describes and claims a system 
having "I/O passthru" to enable each OS in a CEC 
to handle its own I/O operations using dedicated 

TO I/O channels and devices without involving the 
hypervisor. This passthru (or passthrough) feature 
allowed each OS to start 1/0 operations requested 
by application programs running under the OS. and 
to handle the I/O interruptions resulting from such 

rs I/O start operations. The hypervisor only needed to 
intercept an OS I/O operation when an exception 
condition occurred. That invention is used in the 
IBM PR/SM LPAR and &370 VM MPG systems. 
USA patent application serial number 

20 07/752.149 (PO9-91-035) filed on August 29. 1991, 
entitled *CPU Expansive Gradation of I/O Interrup- 
tion Subclass Recognition*, assigned to the same 
assignee as the subject specification, enables a 
significant increase in the number of logical re- 

26 source partitions and CPUs in a CEC. This applica- 
tion enabled each of the CPUs in a CEC (executing 
any OS running in the CEC) to handle all of the I/O 
interruption subclasses avatlat)le in the system: this 
avoided a prior constraint that restricted each OS 

so to only handling interruptions for one of the I/O 
Interruption subclasses available In the system. 

A subchanriel is specified for each I/O device 
supported by an OS under the IBM S/390 architec- 
ture. A SCHIB (subchannel information control 

36 block), stored in system memory when the S/390 
Store Subchannel Instruction (STSCH) is executed, 
is the means for an OS to view its resources for a 
subchannel, including the set of channels usable 
by the subchannel. Each SCHIB contains fields for 

40 up to eight channel identifiers, called channel path 
Identifier (CHPID) values, each of which specifies a 
channel which can be selected for use by the 
subchannel. An available one of the specified 
CHPlDs is selected for each data transmission re- 

45 quest of the subchannel which is not busy at the 
time of a subchannel request. In prior systems 
where I/O devices were directly shared but each 
channel used to access these devices were as- 
signed to a single OS. the SCHIB could only speci- 

50 fy a channel as available when that channel was 
assigned to the OS. 

In prior S/370 and S/390 computer systems, 
each channel was represented by a single 
"channel control block" (CHCB) In a CEC's 1/0 

65 subsystem storage. And each subchannel was also 
represented by a single subchannel control block 
(SCB) in the CEC's I/O subsystem storage. An 
SCB was used by the I/O subsystem internal code 
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(microcode) to select one of up to eight channels 
specified for the SCB for accessing the I/O device 
represented by the SCB (the channel assignments 
of the SCB were the same as in a corresponding 
SCHIB). Each SCB was assigned to one and only s 
one OS in the CEC. Therefore the assigned OS 
was the only OS which could access the subchan- 
nel corresponding to the SCB using passthru to 
Inoprove systen> efficiency (by avoiding hypervisor 
intervention in nr»anaging the I/O operation). No fo 
other OS could directly use the subchannel 

In prior systems where I/O devices were di- 
rectly shared but each channel used to access 
these devices were assigned (dedicated) to a sin- 
gle OS, an adverse consequence was that when a /5 
dedicated channel was utilized only a small per- 
centage of time by its assigned OS. the channel 
could not be dynannically switched to another OS 
using passthru; only non-passthru hypervisor ac- 
cessing (non^direct sharing) was available with its ao 
resulting inefficiencies. Consequently, dedicated 
channels generally remained under-utilized. (The 
available manual switching of a channel to a dif- 
ferent OS did not permit dynamic online switchir^ 
of an I/O channel to another OS.) 25 

Limiting the numl>er of channels to each OS 
had the effect of limiting the I/O data rate available 
to the OS by restricting the number of simulta- 
neous parallel paths for data transmission. 

Prior to invention of logical channel paths for so 
the IBM ESCON I/O Interface architecture, a phys- 
ical relationship existed between either a 
System/370 or 370-XA channel and an attached I/O 
control unit and its associated I/O devices. That is, 
a plurality of physical ports on a control unit were 3S 
respecth^ely connected to different channels, as- 
sodating a different channel with each port. Each 
channel associated with a port was assumed by the 
control unit to be used by a different OS unless a 
special command was received from two or more 40 
of these charmels t>ind(ng them into a channel path 
group for the same OS. The channel path group 
included channel paths connecting the same op- 
erating system to the plurality of ports of a CU, and 
the group was assigned a path group identifier 45 
(PGID). 

Dynamic switching between channels and con- 
trol units USA patent 5.107.489 (P0988011). issued 
April 21, 19d2. entitled "Switch And Its Protocol For 
Maicing Dynamic Connections", was provided by so 
the ESCON I/O Interface architecture. Dynamic 
switching allowed a plurality of channels to connect 
to a single port on a control unit. Instead of each 
channel requiring a connection to a different port. 
These channels could be on the same CEC or es 
different CECs. Dynamic switching also allowed a 
plurality of control unit ports to connect to a single 
channel. 
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USA patent application serial number 
07/576.561. filed August 31. 1990, entitled "Logical 
Channel Paths In A Computer I/O System" (Docket 
Number PO9g0015), assigned to the same assign- 
ee as the subject application, describes the inven- 
tion of logtcal channel paths. The ESCON I/O Inter- 
face architecture eliminated the prior requirement 
f6r a channet-to-port connection by the invention of 
logical channel paths. The concept of logical chan- 
nel paths made it possible for the control unit to 
uniquely recognize any of the plural chanrtels to 
which one of its ports could be dynamically con- 
nected. It also made It possible for the channel to 
uniquely recognize any of the plural control unit 
ports to which it could be dynamically connected. 
The control unit continued to assume that each 
channel capable of connecting to one of its ports 
was to be used by a different OS unless a special 
command was received from two or more of these 
channels binding them into a channel path group 
for the same OS. The channel path group included 
logical channel paths connecting the same operat- 
ing system to the plurality of ports of a CU, and the 
group was assigned a path group identifier (PGID). 

With logical channel paths, each channel and 
control unit port is assigned a link address. For 
each channel capable of being connected to a 
particular contrd unit port, a unique identifier 
(physical channel link address) is assigned, which 
when passed to a control unit port urtiquety iden- 
tifies the channel with respect to ttmt control unit 
port. For each control unit port capable of being 
connected to a particular channel, a unique iden- 
tifier (physical CU link address) is assigned, which 
when passed to a channel uniquely identifies the 
control unit port with respect to that channel. 

The ESCON 1/0 Interface architecture also pro- 
vided for the capability to have a plurality of logical 
control units exist within a physical control unit. 
The ESCON I/O architecture calls these logical 
control units "control unit images", however, herein 
they are called "logical control units". A logical 
control unit provides the functions and has the 
logical appearance of a control unit. When plural 
logical control units do not exist within a physical 
control unit, a single logical control unit is said to 
exist in the physical control unit. Connections be- 
tween a particular channel and control unit port 
could be used for some or all of the logical control 
units which existed in a physical control unit. In 
order to identify the logteal control unit within a 
physical control unit, a unique identifier (logical CU 
address) was assigned to each logical control unit. 

In each frame header sent by a channel to a 
logical control unit, the channel identified the des- 
tination control unit port by including the physical 
CU link address in the destination link address field 
of the frame and identified the destination logical 
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control unit by including the logical CU address in 
the destir^ation logical address field of the frame. 
The channel also included its physical channel link 
. address in the source link address field of the 
frame so that the logical control unit could identify s 
the channel which sent tfie frame. In each frame 
header sent by a (ogical control unit to a channel, 
the togical control unit Identified the destination 
channel by including the physical channel link ad- 
dress in the destination link address field of the 10 
frame. The logical control unit also included both 
the physical CU link address in the source link 
address field of the frame and the logk^ CU 
address in the source logical address fieM of the 
frame so that the channel could identify tfie control « 
unit port and logical control unit which sent the 
frame. 

By placing the proper link and logical address- 
es in the appropriate 30un::e and destination fields 
of each frame header, the communicating channel 20 
and logical control unit are uniquely identified to 
each other. It was the combination of the physical 
channel link address, physical CU link address, and 
k)gical CU address which uniquely identified a sin- 
gle logical channel path, with respect to either a 26 
physical channel or a control unit port. 

Before communication to an I/O device asso- 
ciated with a logical control unit can take place, the 
establishment of a togical path (LP) is required. 
TTie establishing of a logical path is a means for so 
the channel and logical control unit to agree that a 
particular logical channel path is altowed by both 
entities to be used for purposes such as transmis- 
sion of commands, data, and status related to an 
I/O device. The procedure for establishing a logical 36 
path is called the "estabtish-loglcal-path proce- 
dure". A togical path was uniquely identified by the 
combination of the physical channel link address, 
physical CU link address, and logical CU address, 
with respect to either a physical channel or a 40 
control unit port 

Summary of The Invention 

The subject invention significantly increases 45 
the number of images of I/O channels, devices 
(represented by subchannels), and control units 
directly sharabte by a plurality of operating sys- 
tems (OSs) in a computer electronic complex 
(CEC) without requiring an increase in the actual so 
number of physical channels, devices or control 
units connected to the CEC. The OSs can directly 
share all these physical I/O resources without inter- 
vention from a hypervlsor. 

The subject invention also significantly in- 65 
creases the number of images of I/O channels, 
devices (represented by sutrchannels), and control 
units available to each OS in a multi-OS CEC 
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system without requiring an increase in the acfu^ 
number of physical channels, physical devices or 
physical control units connected to the CEC. 

A CEC which supports this Invention may be 
said to support a multiple image facility (MIF). 

The subject invention may significantly in- 
crease the maximum data rate available to each 
OS In a multi-OS CEC system without requiring an 
increase in the actual number of channels or de- 
vices connected to the CEC. The I/O data rate of 
an OS fs dependent on the parallelism of data 
transfer to/from the OS. Increasing the number of 
channels available to each OS can increase the 
number of 1/0 devices which can be simultaneously 
transmitting data to the OS, which can correspond- 
ingly increase the maximum data rate available to 
the OS. 

Increasing the parallelism, flexibility and con- 
nectivity of channels and I/O devices to each OS 
(by increasing the number of channels and I/O 
devices available to the OS) can more quickly 
obtain different types of data for an OS, even when 
this does r^ot increase the overall data transmission 
rate for the OS. The I/O demands of multiple users 
of an OS are better served by increasing the num- 
ber of channels and devices connectable to each 
OS. 

Direct control by each of plural OSs over 
sharable channels and devices by this invention 
increases system efficiency by avoiding hypervisor 
Intervention. Thus, where previously passthru could 
not be used for ail OSs which shared both 1/0 
devices and the 1/0 channels used to access these 
devices, this invention is the means which provides 
this capability. 

The great effective increase in 1/0 channels 
provided by this invention can easily be expressed 
using the following example: If a prior CEC had 7 
OSs and 84 unshared channels, then each OS had 
an average of 12 (=84/7) dedicated channels. With 
this invention, all 84 channels can t>e made directly 
sharable by each of the 7 OSs (while still being 
able to directly share the devices accessible by 
these channels) so that any OS may now use up to 
all 84 channels. Accordingly, the numt)er of chan- 
nels available to any OS has Increased from 12 to 
84, which is a 700 percent increase in this exam- 
ple. 

Of course, any sharable channel may only be 
active on behalf of one OS at a time, t^ause the 
channel is usable for an OS only when it is not in a 
busy state by another OS. In prior CECs. when a 
channel was dedicated to one OS. it could not be 
used by any other OS when it was not busy. But 
with this invention, a sharable channel in a non- 
busy state can be directly used by another OS. 
and can be dynamically switched for direct use 
between different OSs. Thus, a non-busy shared 
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channel may be switched dynamically among plu- 
ral OSs - whenever needed by any sharing OS. 
Plural simultaneous requests to a non-busy channel 
by sharing OSs result in one of the requesting OSs 
getting the use of the channel and the other re- 
quests remaining queued. 

Likewise, any sharable device may only be 
active on behalf of one OS at a time, t)ecause the 
device is usable for an OS only when it is not in a 
busy state by another 0S> In prior CEC$« when a 
device was dedicated to one OS, it could not be 
used by any other OS when it was not busy. BliI 
with this Invention, a sharable device In a non-busy 
state can be directly used by another OS, and can 
be dynamically switched for direct use between 
different OSs. Thus, a non-busy shared device may 
be switched dynamically among plural OSs - when- 
ever needed by any sharing OS. Rural simulta- 
neous requests to a non-busy device by sharing 
OSs result in one of the requesting OSs getting the 
use of the device and the other requests remaining 
queued. 

The invention provides a novel method of shar- 
ing I/O channeis, control units, and devices by a 
number of different OSs by physically providing 
multiple control blocks for the respective use by 
the OSs. each of which specifies a shared resource 
to an OS, and may be said to represent an image 
of the resource to each sharing OS. Thus, a shar- 
ing set of control bloclcs for a sharable resource 
may respectively specify an image of a resource to 
each sharing OS. A sharing set may represent a 
single physical channel, a single control unit, or a 
single subchannel representing a physical I/O de- 
vice, to plural OSs in a CEO. When plural logical 
control units exist within a physical control unit» a 
different sharing set may represent each logical 
control unit. A sharable channel may access dif- 
ferent sharat>le logical control units and sharable 
I/O devices. Likewise, a sharable logical control unit 
may be accessed by different sharable channels. 

Each image of each channel, subchannel, or 
logical control unit is represented in the I/O sub- 
system by use of a hardware or micro-program- 
ming constructs, herein called "channel control 
blocks" (CHGBs), "sharable subchannel control 
blocks" (SSCBs). and "logical control unit control 
blocks" (LCUCBs). respectively. The CHCBs, 
SSCBs. and LCUCBs are all located in the i/O 
subsystem storage of the CEO. 

All control blocks in a sharing set define the 
SAME I/O resource. For example, all CHCBs in a 
sharing set define the same channel to each shar- 
ing OS. Each control block In a sharing set Is 
assigned to a different OS by means of a novel 
"image identifier" (II D). The hypervisor may also 
be assigned a control block in a sharing set. In the 
preferred embodiment. 110 = 0 is assigned to the 
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hypervisor, and the non-zero II Ds are assigned to 
OSs. 

The IID values and the OSs in a CEC need not 
have a one-to-one correspondence when using this 
6 invention. It would be possible for an OS to be 
assigned more fhari one IID fOr its use. But a one- 
to-one correspondence between an IID value and 
OS in a CEC Is used in the preferred embodiment. 

In the preferred embodiment, the HQs are not 
to visible to the OSs, but are for exannple. visible to 
the hypervisor. CPUs, I/O subsystem, and control 
units. 

The IID and the resource number may or may 
not be designated by fields in each control block of 

f5 a sharing set. since these values can be implied by 
the location of the control block in in a two dlmen- 
stonal array In a storage medium. Verification of 
these values is aided by storing them in respective 
fiekjs in each control btock. and these values are 

90 preferably checked in these fields whenever the 
control block is accessed. 

If a sharable resource is selectable by OSs in 
more than one CEC, then the IID for each OS may 
b© further qualified by storing a CEC identifier 

25 along with the IID, e.g. concatenating a unique CEC 
number with the IID used in the CEC (the IID 
needing be unique only within its CEC). II Ds need 
not be unique to a CEC in the preferred embodi- 
ment of the invention, however, a unique CEC 

30 number is not required due to the logics channel 
path addressing provided by the ESCON I/O Inter- 
face architecture. 

The sharable resource identifier may be the 
resource identifier used in a current architecture, 

S5 such as the IBM S/390 architecture's use of the 
"channel path Wentifier" (CHPID) for channel iden- 
tification and "subchannel number" for I/O devtee 
identificatk)n. 

A "sharing set" of control blocks used by this 

40 invention need not comprehend all OSs represent- 
ed in the CEC. By not providing a valid control 
bkx;k for an OS in a sharing set, that OS is 
eliminated from accessing the resource represent- 
ed by the sharing set, because that OS does not 

45 have a valkl Image of the resource. For example, 
one or more SSCBs in a sharing set may be 
missing (or marked Invalid) to prevent some of the 
OSs in the CEC from accessing the device repre- 
sented by that sharing set. Further, the channel 

50 fields in the different SSCBs in the same sharing 
set need not all specify an identical group of chan- 
nels, e.g. some channels may be the same and 
some may be different in the different SSCBs of a 
set. However In the preferred embodiment of the 

66 invention, all OSs are represented in each sharing 
set for each sharable resource, and the same chan- 
nel identifiers are specified in all blocks of a shar- 
ing set of SSCBs. However, some parameters may 
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differ among the control blocks in a sharing set 
without spoiling their image capability. 

In this invention, non-sharing resource control 
blocks (like those found in prior systems) may also 
be intermixed with sharable resources of the same s 
type. Thus, a non-shared subchannel (SCB) may 
be used for an I/O device dedicated to a single OS, 
and sharable subchannels (SSCBs) may also be 
used for enabling passlhru I/O operations by plural 
OSs to that device. io 

This invention is capable of operating with prrar 
CEO resource partitioning architectures that permit 
OS programs executing different resource parti- 
tions of the CEC, such as in IBM PR/SM system On 
which separated resources are defined in different 15 
togicai partitions), or in the IBM S/370 VM MPG 
(Virtual Machine Multiple Prefenred Guest) system 
(which uses software directories to defined different 
k)gtcal partitions). Either of tiiese types of par- 
titioned systems can perform I/O operattons in a 20 
passthru mode which allows OSs to directiy share 
an I/O channel or device (but not both) without any 
intervention from a CEC hypervisor (if no exception 
is encountered) to significantly shorten the time for 
I/O accessing. The I/O channels and devices can- 25 
not t>e both shared for direct accessing by an OS 
in passtiiru mode. In these prior systems, all chan- 
nels and devices can only be accessed by the 
hypervisor; and hypervisor intervention is needed if 
OSs are to share both I/O devices and tiie chan- so 
nels used to access these devices, which is a very 
inefficient type of I/O operation compared to direct 
passthru operations by an OS. 

The sharable channels used by this invention 
may provide bit-serial, bit^parallei or serial/parallel 36 
types of data transmission. The invention is prefer- 
ably used with the serial I/O channel interface of 
the type described by the IBM Enterprise Systems 
Connection (ESCON) architecture because it has 
been found simpler to implement; but this Invention 40 
may be used with other channel architectures. That 
is, ttie IBM ESCON I/O Interface architecture pro- 
vides logical channel paths and logical I/O address- 
ing capabilities for which this invention may be 
easier to implement. 4S 

This invention has found a way to increase the 
number of channels and subchannels available to 
each OS in a CEC without changing the size of the 
channel identifier (CHPIO) value or of the subchan- 
nel identifier (subchannel number) value. With this so 
Invention, the effective number of channels and 
subchannels available to the OSs in a CEC Is a 
multiple of the number of llDs activated in the CEC. 

And the maximum data rate available to any 
OS in a CEC is increased by this Invention en- 65 
ablirig a dynamic shifting on a demand t>asis in the 
use of any shared resource (e.g. channels, sub- 
channels and logical control units) to whichever OS 



in the CEC needs Its use. Dynamic shifting on a 
demand basis significantly improves the utilization 
of the channels in the CEC. 

This Invention expands the use of the source 
and destination address iieUis of each frame head- 
er, as provided by the ESCON I/O Interface ar- 
chitecture, to now include a novel use of the source 
logical address (for frames sent from a channel to 
a control unit) and destination logical address (for 
frames sent from a control unit to a channel). 
These new logical address fields in the frame 
header are used to identify either the image of the 
channel which sent a frame or the Image of the 
channel to which the a frame is being sent. When 
tiie channel sends a frame header, it includes the 
ilD for the con^esponding channel image in the 
source logical address field of the frame. This 
identifies tiie channel image to the control unit. 
When a control unit sends a frame header, it in- 
cludes the IlD for the conresponding channel Image 
in the destination logical address field of tfie frame. 
This identifies the channel image to the channel. 

This invention expands the identification of a 
togical channel path and logical path (LP) to in- 
clude the IlD corresponding to a channel image. A 
single logical channel path or logical path is 
uniquely identified by the combination of the phys- 
ical channel link address, physical CU link address. 
IlD, and k)gk:al CU address, with respect to either a 
physical channel or a control unit port. 

The IlD need not be the actual value used In 
the frame t^eader to identify the channel image. It 
would be possible to use another identitier which 
had a one-to-one correspondence with the IlD. 
However, the IlD value is included in tiie frame 
header in order to kientify the channel image in the 
preferred embodiment 

With this invention, the IID in a frame header 
can be used for both shared and unshared chan- 
nels. For unshared channels, a single channel im- 
age and a single channel control block are used 
(for the dedicated channeO* 

The infonnation in each frame transferred 
through any physical channel is always restricted 
to the OS assigned the IID in the frame header. 
The frame is isolated from all other OSs (using a 
different IID in their frames), and the IID logic for 
supporting the images of a channel, subchannel, or 
togical control unit within a CEC maintains this 
restriction. 

This invention also comprehends use of a dy- 
namic channel switch (called a "director") to sjp- 
port multiple channel images by assigning multiple 
link addresses to alt of tiie images of the shared 
channels within the l*0 subsystem of a CEC, e.g. 
one link address per channel image. This Is a non- 
preferred versron of this invention for handling the 
images within a CEC, because the director does 
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not know how many images of a channel a CEC 
supports or Is currently configured with, and so 
would have to assign the maximum number to 
each channel, which would deplete the numt>er of 
link addresses available and produce a more com- 
plex director port design in the director. Tliis tech- 
nique would also require the director to know which 
ports had channels attached and which of these 
were shared channels. 

With the previously-summarized preferred form 
of this invention, a single port is required to attach 
either a shared channel or a unshared chanriel to a 
director and the director assigns a single link ad- 
dress to the physical channel. It is the II D included 
in the frame header which is used to uniquely 
identify the channel image of a physical cfiannet. 

Brief Description of the Drawings 

Rg. 1 

illustrates a computer electronic complex (CEO) 

using the invention. 

Rg.2 

shows physical channel links connecting directly 
to control units (CU> ports without going through 
a dynamic switch. 
Rg.3 

shows physicai channel links connecting to con- 
trol units <CUs) through a dynamic switch, 
Rg.4 

illustrates a "control unit logteat path control 
block" (CULPCB) used in representing a logical 
path within a logical control unit in a memory 
used by the control unit. 
Rg-5 

represents a frame header (containing logical 
path identifier components) transmitted by a 
CEC to an I/O control unit. 
Rg.6 

represents a state descriptor (SD) control block 
of a SIE (start interpretive execution) instruction 
used for indicating the resources assigned to a 
partition in a computer electronic complex 
(CEC). 
Rg.7 

represents a start subchannel (SSCH) instruction 
and its operands for use by an embodiment of 
the invention. 
Rg.8 

is an example of an array containing channel 
control btocks (CHCBs) used in an embodiment 
of the invention. 
Rg.9 

Illustrates an example of the content of a con- 
figuration control block (COB) used to activate 
the I IDs whk^h may be used by operating sys- 
tems in a CEC. 
Rg. 10 
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illustrates an example of the content of a chan- 
nel control block (CHCB) used in an embodi- 
ment of the invention. 
Rg. 11 

6 is an example of an anray containing both non- 
shared subchannel control blocks (SCB) and 
shared subchannel control bk>cks (SSCB) used 
in an embodiment of the invention. 
Rg. 12 

to illustrates an example of the content of an SSCB 
or SCB used in an embodiment of the Invention. 
Rg. 13 

Is an example of an array containing logical 
control unit control blocks (LCUCBs) used in an 
/5 embodiment of the invention. 
Rg. 14 

illustrates an example of the content of a logical 
control unit control block (LCUCB) used in an 
embodiment of the invention. 

20 Rg. 15 

represents a working queue (WQH). a control 
unit image queue (using a LCUCB as a header), 
and an interruption queue (IQH) used by an 
embodiment. 

26 Rg. 16A and Rg. 16B 

together show an integrated embodiment of the 
invention having different types of control blocks 
representing various types of ItD-assoctated im- 
ages for a plurality of operating systems. 

so Rg. 17and Rg. 18 

provide a flow-diagram of a start sut>channel 
instruction in the preferred embodiment. 

Description of The Detailed Embodiments 

35 

Computer Electronic Complex (CEC): 

Rg. 1 shows a computer electronic complex 
(CEC) used with an embodiment of the invention. 

40 The CEC includes one or more central processors 
(CPUs), a system memory, caches and controls 
(not shown) of the type found in the prior art for 
interconnecting the CPUs to the system main 
memory, and an I/O subsystem. The CEC re- 

45 sources in FIGURE 1 are configured into resource 
partitions 1 through N. which may be done in the 
manner described and claimed In USA patent 
4.848,541 (previously cited herein). 

Each of the N partitions In the CEC shown in 

50 Rg. 1 contains an operating system (OS), and a 
microcode hypervisor (such as the IBM PR/SM 
microcode hypervisor) controls the overall opera- 
tion of the OSs. Altemath^ely. the CEC may contain 
a plurality of OSs that operate under a virtual 

65 machine (VM) software hypervisor. In either case, 
the CEC has N numt)er of OSs simultaneously and 
independently executing under control of a hyper- 
visor. The OSs may, for example, be copies of the 
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IBM MVS and/or VM CMS systems. 

The I/O subsystem in Rg. 1 includes I/O pro- 
cessors (lOPs) 1 through T, and channel proces- 
sors (CHAN PROCs) 1 through S. The I/O sub- 
system may, for example, have up to 256 channel 
processors (when using an eight bit OHPID), and 
usually has a lessor number of lOPs. The lOPs 
remove the I/O requests received from the CPUs 
via an I/O work queue and select a channel proces- 
sor for controlling the requested I/O operation. The 
number of lOPs is determin«j by whatever numfc>er 
can handle the I/O work load from the CPUs in a 
timely manner. Usuaily only a few 10 Ps are re- 
quired, such as four lOPs. which are presumed in 
the prefenred embodiment. The channel processors 
respectively control data transmissions on channels 
1 through S, each of which may be a serial channel 
of the IBM S/390 ESCON type In the preferred 
embodiment 

This invention enables plural OSs simulta- 
neously executing a plurality of I/O channel pro- 
grams to directly and effidently share the lOPs and 
I/O channels. 

The sharing of the I/O resources utilizes three 
types of images of I/O resources, including I/O 
channel images, logical control unit images, and 
device images via subchannel images. 

Each physical channel is represented by a 
sharing set of channel control blocks (CHCBs). The 
CHCBs are located in I'O subsystem storage. The 
I/O sut>system storage is preferably separate from 
(for protection from) CPU program addressable 
storage. 

Each OS has a different "channel image*' of 
the same physical channel. The different channel 
images of the same physical channel are repre- 
sented by information in each of the CHCBs of the 
sharing set. Each channel image is defined herein 
by an OS identifier (IID) and a physical channel 
identifier (CHPID). The CHCB tor a particular chan- 
nel Image can be located in I/O sut>-syst0m stor- 
age by its associated CHPID and IID values. Var- 
ious characteristics for each of the channel images 
for the same physical channel are indicated by 
settings in the CHCBs for the respective channel 
images. 

An image of the channel is used as a compo- 
nent in defining a logical path (LP) from a particular 
OS through the associated physical channel to a 
logical control unit (including through any 1/0 dy- 
namic switch). A single logical path is uniquely 
identified by the combination of the physical chan- 
nel link address, physical CU link address. IID, and 
logical CU address, with respect to either a phys- 
ical channel or a control unit port. Different I/O 
channel programs operating under different OSs 
may be simultaneously executing by using different 
images of the same physical channel, although 



only one channel program can be transmitting 
commands, data, or status through the physical 
channel at any one time. FIGURES 8 and 10 show 
CHCBs. and show how they are organized in an 
s array such that they can be located by CHPID and 
110 values. 

Each suixhannel is represented by a sharing 
set of shared subchannel control blocks (SSGBs). 
The SSCBs are located in I/O subsystem storage. 

TO The I/O subsystem storage is preferably separate 
from (for protection from) CPU program addres- 
sable storage. 

Each OS has a different "subchannel image" of 
the same subchannel The different subchannel 

75 images of the same subchannel are represented by 
information in each of the SSCBs of the sharing 
set Each subchannel image is defined herein by 
an OS identifier (IID) and a sutM:hannel identifier 
(subchannel number). The SSGB for a particular 

20 subchannel image can be located In I/O subsystem 
storage by its associated subchannel numtwr and 
IID values. Various characteristics for each of the 
subchannel images for the same subchannel are 
indicated by settings in the SSCBs for the respec- 

25 five sutx^hannel images. 

Different I/O channel programs operating under 
different OSs may i^e simultaneously executing and 
sharing the same subchannel (the same device) by 
using different images of the same subchannel, 

30 although only one channel program can be acces- 
sing the device at any one time. Figs. 11 and 12 
show SSCBs. 

Each logical control unit is represented by a 
sharing set of logical control unit control blocks 

36 (LCUCBs). The LCUCBs are kDcaled in I/O sub- 
system storage. The I/O sut>system storage Is pref- 
erably separate from (for protection from) CPU 
program addressable storage. 

Each OS has a different ^'logical control unit 

40 image** of the same logical control unit The dif- 
ferent logical control unit images of the same logi- 
cal control unit are represented by information in 
each of the LCUCBs of the sharing set. Each 
togicai control unit image is defined herein by an 

45 OS Identifier (IID) and a k>gical control unit iden- 
tifier (LCUCB number). The LCUCB for a particular 
togtcal control unit image can be located in I/O 
subsystem storage by its associated LCUCB num- 
ber, and IID values. Various characteristics for each 

so of the logical control unit images for the same 
logical control unit are indicated by settings in the 
LCUCBs for the respective logical control unit im- 
ages. 

Different I/O channel programs operating under 
65 different OSs may be simultaneousty executing and 
sharing fhe same logical control unit by using dif- 
ferent images of the same logical control unit, 
although only one channel program can be trans- 
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mitting commands, data, or status through a par- 
ticular physical channel and control unit port at any 
on© time. Figs. 13 and 14 show LCUCBs. 

Although this invention supports shared chan- 
nels, shared control units, and shared subchannels, 
this invention also permits a CEC to have and be 
using unshared channels, unshared control units, 
and unshared subchannels (devices) while it is 
using the shared I/O resources. A particular chan- 
nel, control unit, or subchannel may be changed 
from either unshared to shared, or from shared to 
unshared by dynamically or statically reconfiguring 
the CEC resource assignments. 

The image concept of this invention allows only 
the OS associated with a particular image resource 
identifier (II D) to access information acquired with 
the use of that OS's image identifier. The use of 
shared resources by this Invention need not affect 
the privacy of I/O infonnation an OS accesses. 
That is, each OS sharing the same physical re- 
sources with other OSs maintains its security of I/O 
information from all ottier OSs sharing the re- 
sources. And no OS need view its 110 or any other 
no. In the preferred embodiment, the IIDs are not 
visible to the OSs. but are for example, visible to 
the hyparvisor, CPUs, I/O stdssystem. and control 
units. 

Channel Paths to I/O Devices: 

Fig. 2 illustrates a set of physical channel links 
from the CEC in Rg. 1. Concurrently executing 
channel programs in different OSs in the CEC may 
be using any single physical channel path to ac- 
cess the same or different I/O devices when using 
this invention. Any channel path may include ele- 
ments such as any of the channels 1-S from the 
CEC to any of control units (CUs) 1 through R. 
These CUs connect to I/O devices A, E ... Y, Z. 
Although channels 1-S are shown respectively con- 
rtected to S number of ports on each CU, it should 
be understood that any CU may have anywhere 
from one to S number of ports. Each of the chan- 
nels 1-S may be connected to a different port of a 
CU. An6, some channels may not t)e connected to 
a particular CU. 

Fig. 3 shows the same physical channel linl<s 
1-S connected through a dynamic switch 11 to the 
same control units (CUs) 1-R. The advantage of 
dynamic switch 11 is to obtain the same connec- 
tivity of channels to CUs (as was obtained in Fig. 2 
without a dynamic switch), except that in Fig. 3 
each CU has only a single port to which any of 
channels 1-R may fc>e connected. Thus, the dy- 
namic switch 11 eliminates the need for multiple 
CU ports to obtain flexible channel-to-CU connec- 
tivity. The CUs in Rg. 3 are assumed to connect to 
the same sets of I/O devices A, E ... Y, Z as in Fig. 
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2. 

Figs. 2 and 3 are intended to show that the 
invention comprehends all manners of obtaining 
physical channel-to-CU paths, whether or not any 
6 dynamic switch is provided in the connection path, 
and whether or not the CUs have one or multiple 
ports. A dynamic channel switch is sometimes 
called a "director*. 

to OS Image Identifier (IID): 

One or more different "image identifiers" (IIDs) 
are assigned to each of the plural OSs executing In 
different resource partitions of the CEC in Rg, 1 , In 

/s the preferred embodiment herein, one IID is as- 
signed to each OS in a CEC. 

Although assigned to OSs. in the prefenred 
embodiment, the IIDs are not visible to the OSs. 
But for example, they are visible to the hypervisor, 

80 CPOs, I/O subsystem, and control units. 

The IIDs are used to enable the plural OSs to 
share the physical I/O resources connectable to the 
CEC without decreasing the data security between 
the OSs. The new-found sharability provided by 

25 this invention enables up to all of the OSs in a CEC 
to share up to ail of the I/O channels, up to all of 
the control units (both physical and logical) avail- 
able to the CEC, and up to all of the I/O devices 
connected to the control units, without involving the 

30 hypervisor in the I/O operations. 

The invention enables the OSs to use different 
images of the same channels, suk>channels 
(representing 1/0 devices) and logical control units. 
The different images enable individual sharing and 

35 control by each OS of the same physical channel 
and/or of the same control unit (both physical and 
logical), and/or of the same physical I/O device. 

Rg. 16A represents an example of channel 
Images, logical control unit images, and sutxhan- 

40 nel Images by means of control blocks stored in a 
CEC's I/O subsystem storage. A control unit also 
has control blocks stored in I/O control unit storage 
which represent logical paths, as shown in Rg. 
18B. It is the use of these control blocks by the I/O 

45 subsystem and the CU which permits the different 
OSs to access and directly share all the same I/O 
resources. 

Multiple images of the same sutxrhannel pemnit 
each OS to be connected (through an OS-related 
50 image of the same subchannel) to the same de- 
vice. 

Different OSs sharing a physical channel may 
asynchronously multiplex data through the same 
physical channel at different times to the same I/O 
S5 device or to different I/O devices. 

Each of the different channel images is repre- 
sented by a channel control block (CHCB) in the 
I/O subsystem storage. The I/O subsystem storage 
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IS preferably in a memory area separate from sys- 
tem main storage, so that the I/O subsystem stor- 
age IS not addressable by CPU Instructions, but Is 
addressable by internally coded (microcoded) 
instructions, and hardware. Examples of CHCBs 
are shown in Rgs. 8. 10 and 16A. There may be 
up to (N + inp-K 1) of sharable CHCBs in I/O sub- 
system storage. 

The preferred embodiment assigns a unique 
non-zero llD value to each OS in a CEC, and 
reserves the ltD=:0 value for assignment to the 
CEC hypervisor. The hypervlsor may or may not 
actually be assigned any II D value. 

The requirements of different hypervisors vary 
in relation to whether they need to be able to 
perform 1/0 operations on their own behalf. For 
example, If a software hypervisor is used, it should 
be able to share I/O devices with its OSs; and then 
a shared subchannel control block (SSCB) having 
an IID=0 may be provided in each sharing set of 
SSCBs for use by the hypervisor. Likewise, a 
CHCB and LCUCB having an IID = 0 may be pro- 
vided in each sharing set of CHCBs and LCUCBs, 
respectively. This allows a software hypervisor 
(such as VM/370 XA) to share I/O channels. CUs 
and devices with its OSs. On the other hand, if a 
mterocode hypervisor Is used (e.g. the hypervisor 
in the IBM PR/SM LPAR system), it need not share 
I/O resources with the OSs, in which case no 
SSCB, CHCB. or LCUCB for the hypervisor (having 
an IID^O value), need be provided in each sharing 
set. 

The preferred embodiment makes the II D$ 
transparent to all OSs in the CEC, and to all 
programs executing under the OSs. It is not neces- 
sary to have any OS, or OS program, be aware that 
llDs are being used in the CEC. or that I/O re- 
sources are being shared by the OSs. Only the 
system hypervisor. CPUs. I/O sub-system, and 
control units need to be aware of IIDs and resource 
sharing. No OS needs to view or access any IID 
value, since the OS's IID value is automatically 
handled by the hypervisor. CPU, I/O subsystem. 
STKl control unit corrtrols (including its system 
microcode and hardware operations) whenever an 
OS requests an I/O operation. And programs ex- 
ecuting under any OS (e.g.in any logical partition or 
'm any virtual machine in a CEC) need not be 
aware of the existence of IIDs. 

IID Value Activation: 

Fig. 9 illustrates a configuration control block 
<CCB) In which the various IID numbers are ac- 
tivated or inactivated for use by the CEC oper- 
ations. A bit position is provided for each possible 
IID value from zero up to a maximum. A bit posi* 
tion corresponding to a particular IID value is sat to 
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a one state to activate tiiat IID value, or is set to a 
zero state to indicate an inactive state for that IID 
value. 

If each IID Is represented by an 8-blt number, it 
5 allows up to 255 non-zero values, of which, for 
example, 63 may be activated and assigned to 
OSs of a resource-partitioned CEC. The IIDs could 
be specifM by a larger or smaller number, and 
more than one IID could be assigned to any OS, 
TO although in the preferred emix)diment there is only 
one IID assigned to any OS. 

No requirement exists for the activated IID val- 
ues to start at any given value or be in a dense 
range of IID values. For example, an implementa- 
fs tion could provide a set of four active llD values 
such as 0, 2, 7, and 8 for four associated OSs. 

Assignment of an IID to an OS: 

20 An IID is assigned to an OS by storing the IID 

value in a hypervisor control block, called a SD 
(state description) which is the operand of a SI E 
(start interpretive execution) instruction, executed 
only by the hypervisor for dispatching any OS. An 

26 exemplary form of an SD is shown in Fig. 6. A 
respective SD is provided in system main storage 
for each OS operating under the hypervisor in 
order to define the subset of CEC resources avail- 
able to each OS. Accordingly, an 110 is assigned to 

30 an OS when the assigned IID value is stored in the 
110 field in the SD assigned to the respective OS. 
The SDs are not accessible to the OSs in this 
embodiment. 

When an I/O command is issued by any OS. 

35 the OS's IID is usually required in the execution of 
tiie command. The hypen/lsor or microcode ac- 
cesses the IID in the SD. and microcode controlling 
the execution of the command for the respective 
OS. applies the IID for the current OS command 

40 without the OS having any access to the IID. The 
microcode locates and accesses any required 
CHCB, SSCB, and/or LCUCB to select any chan- 
nel, subchannel, or logical control unit images re- 
quired for performing the OS command, setting up 

45 any required logical path (LP) specification, gen- 
erating a frame header (containing all addresses 
required at the CU), and transmitting the frame 
packet on the selected physical channel path to the 
CU for accessing a requested I/O device (also 

50 addressed in the frame header). The CU stores tiie 
communicated LP specification (including its IID) 
for use by the CU when the CU later must respond 
to the request (after performing the requested com- 
mand). 

55 
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Channel Images (CHCBs): 

Images of each channel are provided by chan- 
nel control blocks (CHCBs) which are used In asso- 
ciation with other control blocks. Each physical 
channel is identified by a respective CHPID num- 
ber. 

Not ail of the channels need to be shared, and 
In Fig. 8» channels corresponding to CHPIDs 0 
through 4 are not shared and are assigned to either 
the hypervisor <I1D=0) or one of the OSs <IID other 
than zero). Any number, including all or none, of 
the channels may be shared. In Fig. 8. the chan- 
nels having CHPIDs higher than 4 are shared by all 
N OSs and CHPIDs 0 through 4 are not shared. 

Each CHPiD may have a plurality of channel 
images (CHCBs) up to the number of IIDs (equal to 
the number of OSs). Each of the channel images 
independently represents a physical channel to a 
respective OS, so that the OSs can independently 
operate the physical channel. That is, each OS 
which uses a particular physical channel has Its 
own channel image different from the chanrwl im- 
ages of the other OSs for the same physical chan- 
nel Thus, each channel image for any OS may 
have states different from, and independent of, the 
channel Image of any other OS for the same phys- 
ical channel. 

Fig. 8 shows an example of an array of CHCBs 
0(0) -P(N) that represent an channel images for all 
physical channels in a CEC. The respective CHCBs 
are indexed (located) in the array by their assigned 
CHPID. which is written into the first field of each 
CHCB in the preferred embodiment in which each 
CHPID is represented by an eight bit number that 
limits the maximum number of CHPIDs (and the 
corresponding number of channels in a CEC) to 
256. (Note: this example is not the array of CHCBs 
shown in Rg. 16A in which only CHCBs for shared 
channels are shown.) 

Structure of an CHCB: 

Fig. 10 shows the content of a CHCB (which is 
also the content of the CHCBs used in FIGURE 
16A). The first row In each CHCB contains the 
value of the CHPID represented by tfie respective 
CHCB. An IID field contains the I ID assigned to this 
CHCB. These two values, the CHPID and 110, to- 
gether locate any CHCB in the I/O subsystem 
storage, where they are used for accessing any 
CHCB in the channel operations. Other fields in 
each CHCB are: 

U: Unshare/shared Indication Indicates If the 
channel is being unshared (dedicated to one OS), 
or Is shared by a plurality of OSs. 

C: Varied onllna'offline indication which indi- 
cates if the re^active channel image is varied 
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online where it can be operational, or varied offline 
where ft cannot be operational but where it can be 
serviced for a maintenance operation. 

P: Permanent Error: Indicates whether the 
6 channel image is currently in a permanent error 
condition or not. 

A: Candidate: Indicates whether the channel 
image is permitted to be varied online. 

S: Suppressed: Indicates whether new I/O ac- 
to tivity may be initiated for the channel Image- 
There may be other fields (not shown) in each 
CHCB, in addition to these defined fields which are 
not unique to the CHCBs in this specification. 

The following (and many other) scenarios are 
ts possible in the states of these novel channel im- 
ages for the same or different physical channels: 

a) Shared channel images for OSs 1, 2 and 3 
are varied online. 

b) The channel image for OS 1 is varied offline 
20 and is not operational, while the channel images 

for OS's 2 and 3 are varied online and are 

concurrently perfonning I/O operations. 

c) A momentary enror corKlition has occurred in 
the physical channel which causes the channel 

25 images for OS's 2 and 3 to be placed in the 
permanent error state. (The channel image for 
OS 1 is offline, as varied by the previous step). 

d) In order to again use its channel image. OS 2 
varies Its channel image offline, and then varies 

30 the channel image online which cures the error 
condition and makes the channel image enror- 
free. This results in the three channel images 
ending up in a different state: The OS 1 channel 
image is offline; the OS 2 channel image is 

3S online and error-free, and the OS 3 channel 
Image is online and in permanent error. 

Other Control Blocks per Channel: 

40 Other control blocks are used in the operation 
of the channels, such as for example, a "reverse 
lookup control block" (RLCB) associated with each 
CHCB. The RLCB lists each subchannel which can 
use a respective physical channel. 

46 If there is a channel assignment variation in the 

subchannel images (SSCBs for the same sharing 
set), In which some sutx:hannels In the sharing set 
can use a particular channel and other sutxhannels 
in the same sharing set may not, such variation 

50 might also be listed In the RLCB. (However, the 
preferred embodiment herein assigns the same 
channels (CHPIDs) to all SSCBs in the same shar- 
ing set). 

55 Subchannel Images <SCBs and SSCBs): 

This invention provides a set of subchannel 
Images for each subchannel by means of a 
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''sharing set" of SCBs» herein called "sharing 
SCBs" (SSCBs). The SSCBs in a sharing set are 
respective assigned to different II Ds (representing 
different OSs). The novel concept of a sharing set 
enables up to all OSs in a CEC to access the same 
device (because the same subchannel number, re- 
presenting the same device, is assigned to all 
SSCBs In the same sharing set). 

Rg. 11 shows an example having t>oth sharing 
sets of SSCBs and non*shared SCBs. Each box in 
Rg. 11 represents an SSCB or an SCB. They are 
arranged vertically in Rg. 11 according to subchan- 
nel numt>ers A to Z, in which the subchannel 
numbers correspond to the 1/0 devices in Rgs. 2 
and 3. Subchannel numbers A-E represent only 
non- shared SCBs. Each of the subchannel num- 
bers F-Z represent a sharing set of SSCBs. As 
previously stated, each subchannel is assigned to a 
different I/O device. 

The top row In Fig, 1 1 indicates the OS owner- 
ship of the SSCBs. Each column is respectively 
assigned a different liD from 0 to N to indicate the 
OS ownership of the SSCBs in the respective col- 
umn. In column IID = 0. the SSCBs belong to the 
hypervisor, since IID=0 is assigned to the hyper- 
visor in the preferred embodiment. 

Accordingly, each of the subchannel numbers 
A-E locates a non-^shared SCB assigned to either 
the hypenrisor (I ID =0) or one of the OSs (MD other 
than zero). And each of the sutx^hannel numbers F- 
Z is assigned to a sharing set of SSCBs for en- 
ablir^g its represented I/O device to be shared by 
the hypervisor and by each of the OSs having II Ds 
1-N. The shared device will also share one or more 
channels when the same CHPIDs are specified in 
each of the SSCBs in the sharing set. as Is done in 
the preferred embodiment herein. 

Although each of the SSCBs in a sharing set 
may be considered to provide a "subchannel im- 
age" of each other, because they all apply to the 
same subchannel these SSCBs only represent 
"complete subchannel images" of each other when 
they all have the same CHPID (channel) assign- 
ments. 

A sharing set may contain "partial subchannel 
images" when some SSCBs in the sharing set do 
not have all of the CHPIDs specified in other 
SSCBs in the set. But a sharing set supports 
"shared channels" when two or more SSCBs in the 
sharing set have the same CHPID to enable dif- 
ferent OSs to share the same channel when acces- 
sing the I/O device represented by the sharing set 

In the preferred embodiment herein, every 
SSCB in the same sharirtg set has the same 
CHPIDs, but different sharing sets have different 
sets of CHPIDS. although they may have some or 
all CHPIDs in common. 
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Structure of an SSCB: 

Fig. 12 shows the content of each SSCB and 
SCB shown in Fig. 11 (SSCBs and SCBs are 
5 Identicat in field structure and differ »n whether or 
not they are used in sharing sets). Some of the 
fields in the illustrated SSCB/SCB content are iden- 
tical to fields in the SCHIB (subchannel infbrmation 
block) found in the prior S/380 architecture. How- 
w ever, novel fields provided In the SSCB/SCB herein 
include an IID field, a chain pointer field, a QID 
field, an I/O interpretation control bit field (INCB). 
LCUCB number field, and an SSCB number field, 
which are defined as follows: 
15 a. The INCB (I/O interpretation control bit) field 
irxficates whether the subchannel image is en- 
abled for instruction and interruption interpretar 
tion or not. 

b. The chain pointer field in the SSCB allows it 
20 to be chained into any of several types of 
queues which perform a function used for se- 
lecting SSCBs, such as a "start subchannel 
work queue" and a "device interruption queue", 
such as the queues shown in Fig. 15. 
26 c. The QID field content specifies a particutar 
queue containing the SSCB (which applies to 
the pointer value in the chain pointer field). 

d. The IID field contains the assigned HD value. 

e. The LCUCB number field contains the logical 
so control unit identifier of the LCUCB associated 

with the SSCB. The LCUCB number and IID 
fields are used in combination to locate the 
associated LCUCB in I/O subsystem storage. 

f. The SSCB number field contains the related 
3B SSCB (or SCB) value. 

The IID field and the SSCB number field con- 
tents are provided for verification checking. The 
v^ues in these fieMs are implied by the location of 
the respective SSCB in the array shown in FIGURE 

40 11 (so theoretically these values are not needed to 
specify the SSCB or SCB). 

The SSCB number field is required by this 
invention to contain the same SSCB number in 
every SSCB in the same sharing set. 

45 The other fields in the SSCB/SCB shown in 

FIGURE 12 may be the same as the fields defined 
In the prior art SCHIB in the ESA/390 Principles of 
Operation (previously cited herein), and they may 
also be provided in each SSCB. However, some of 

50 these fields found in the prior SCHIB are used In a 
novel manner by this invention, such as the follow- 
ing: 

A valid field V indicates if the image repre- 
sented by the SSCB Is valid and may be used: If 
55 invalid, the represented image of the device cannot 
be accessed by the assigned OS (represented by 
its assigned IID). However, the same device may 
be accessed by other OSs having valid inuiges of 

14 
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the same subchannel indicating by a valid state 
(having thefr valid bit = 1, but assigned different 
ilDs). Hence, the V bit in each subchannel image 
can be set to either one or zero in order to allow 
only selected OSs to request 1/0 operations of the 
corresponding I/O device. 

In the preferred embodiment each SSCB or 
SCB contains fields for up to eight CHPIDs 
(CHPID-O to CHPID-7)» which allows the device 
represented by a SCB or SSCB to be accessed 
through any of up to eight different channels repre- 
sented by these CHPIDs. When a device is t>eing 
selected for a communication operation (such as 
when a device is being started or is being reset), 
some of its CHPID-specified channels may not be 
usable by the requesting OS, due to being busy 
with other devices, or merely not being currently 
operational. When a channel is found available, it is 
assigned as the currently selected channel path to 
the device represented by the SCB or SSCB. 

Enabled bit. E, indicates whether I/O operations 
may be performed by the image represented by 
this SSCB. The E bit value may be different for the 
different SSCB images in the same sharing set. 

I/O Interruption subclass code. ISC. indicates 
the intenrupt subclass used for an I/O interruption 
provided for the image represented by this SSCB. 
The ISC values may be different for the different 
SSCB images in the same sharing set. 

Logical Path Mask. LPM. indicates the logical 
availability of the cfiannels q^ecified by the CHPIDs 
in the SSCB for accessing the I/O device specified 
by the subchannel numiDer in the SSCB. The LPM 
field value may be different tor the different SSCB 
images in the same sharing set. 

Path Available Mask, PAM. has 8 bets which 
respectively indicate the physical availability of 
each of the installed channels specified in the 
CHPIDs 1-6 fields in the SSCB for use by the I/O 
device specified in the subchannel number field. 
The PAM field value may be different for the dif- 
ferent SSCB images in the same sharing set 

A DB (device busy) field indicates whether the 
last request in the current k>gical channel path for 
this SSCB has encountered any device busy con- 
dition for which a device end condition has not yet 
been received. The DB field value may be different 
for the different SSCB images in the same sharing 
set 

An allegiance field. ALLEG, indicates for the 
currently assigned channel path for this SSCB im- 
age which, if any. of the following allegiance states 
apply: 0. no allegiance. 1. active allegiance, 2. 
dedicated allegiance, or 3. working allegiance. The 
ALLEG field value may be different for the different 
SSCB Images In the same sharing set. 

These and other subchannel control fields pro- 
vide the I/O sub-system with the capability of in- 



dependent y keeping track of each subchannel im- 
age's state and attributes. For example, items such 
as path selection management, path availability, 
device busy condittons. and allegiances can all be 

6 handled independently for each subchannel image 
within each sharing set. 

Generally, the IID values in the SSCBs (and in 
any SCBs) are established at the time a I/O sub- 
system is initialized, or is reconfigured. When a 

to software hypervisor Is used with the CEC, control 
blocks associated with unshared sutxihanneis 
(SCBs) are set to an IID value equal to zero, which 
allows the software hypervisor to control the I/O 
operations performed on these subchannels. But 

15 when a microcoded hypervisor is used with the 
CEC. control blocks associated with unshared sub- 
channels (SCBs) are set to an 1 ID value of an OS 
when a channel is varied online to that OS. 

Further, if the same channel (CHPID) is speci- 

20 fled in all SSCBs In a sharing set that channel is 
shared by all OSs in the CEC for making a connec- 
tion to the device represented by the sharing set of 
SSCBs. Thus, the IID assignments to all SSCBs in 
a sharing set enable all OSs in the CEC to share 

25 any channel specified by a CHPID found in all the 
SSCBs in the sharing set. 

Isolation of Shared Channels and Shared Subchan- 
nels: 

30 

Each of the OSs can operate a physical chan- 
nel or a physical 1/0 device indep^endently of the 
other OSs through the use of images of these 
channels and subchannels. No software coordina- 
35 tion is required among these OSs in their use of 
the physical channels and I/O devices. All co- 
ordination among the OSs is automatically done 
through the image control blocks such as the 
CHCBs and SSCBs. and other image control 
40 blocks to be described herein. 

The identification of control blocks with di^ 
f^ent lIDs enables the different OSs to indepen- 
dently issue subchannel related I/O instructions to 
the same shared I/O device through shared chan- 
ts nets without physical Interference among the OSs, 
and with the information transmitted for each each 
OS being completely secure from the operations 
done with the same physical transmission media 
by the other OSs. It must be understood that 
so information residing on a shared I/O device is the 
responsibility for each OS to make secure from 
other OSs. 

Although the different OSs view the same sub- 
channel numbers, (same I/O device identifiers) and 
65 same CHPIDs (channel identifiers) in the sharing 
sets, no OS can access the channel or sut)channel 
image associated with another OS. because locat- 
ing any channel image or subchannel image re- 
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quires an IID value not viewed by the OSs (no OS 
has access to the UD values), and can only be 
accessed by the hypervlsor. CPUs, and I/O sub- 
system. Accordingly, the lack of access to the IID 
values, and the inability of the OSs to access the 
I/O subsystem control blocks is enforced by putting 
the ilDs in control blocks In storage media that are 
not addressable by any OS executed instruction, 
which prevents any operation by or>e OS from 
interfering with the operations of any other OS. 

Address Generation for SSCBs and SCBs: 

The address of a required SSCB or SCB is 
obtained by the microcode executed for an OS 
instruction requesting an I/O operation. The SSCBs 
In FIGURE 11 are in the storage of the I/O sub- 
system, vrtiich is not addressable by OS executed 
instructions (which in this embodiment are in the 
system area of an IBM S/390 compatible system). 
An SSCB is accessed by generating a storage 
address given a subchannel number and an IID 
value. 

The address of a required SCB or SSCB can 
be determined by: multiplying its subchannel num- 
ber by the size of each SCB or SSCB and adding 
this result to the proper base address. There is a 
single proper base address which is used for ali 
SCBs, and there are multiple base addresses (one 
for each IID provided in the CEC) that are used for 
SSCBs. The proper t^ase address for a SSCB Is 
the one which corresponds to the IID field in the 
SSCB. In the preferred embodiment, all the base 
addresses are calculated at the time the i/O sub- 
system is initialized. This makes the calculation of 
a SCB or SSCB address much faster than if the 
base address were to be calculated each time it is 
needed. The calculation of the base addresses is 
dependent on whether a single, continuous range 
of storage addresses are used for alt SCBs and 
SSCBs or whether multiple* continuous ranges of 
storage addresses are used for the range of SCBs 
and ranges and SSCBs associated with different 
llDs. 

Address Generation for CHCBs and LCUCBs 
can be done in a manner similar to SCBs/SSCBs. 
For CHCBs, it is a CHPID and IID which uniquely 
idsrvtify a CHCB. For LCUCBs. it is a LCUCB 
number and IID which uniquety Identify a LCUCB. 

Expansion of the Number of Channels and Sub- 
channels: 

The Invention can expartd the effective number 
of available channel and subchannel images in a 
CEC far beyond the maximum number provkled by 
the largest number available from the number of 
bits in the CHPID and subchannel number values. 



The maximum number of channel images available 
to a CEC is equal to the maximum number of 
channels multiplied by the number of 11 Ds in the 
CEC. And. the maximum numt)er of subchannel 
5 images available to a CEC is equal to the maxi- 
mum number of subchannels multiplied by the 
number of IIDs in the CEC. This occurs because 
each CHPID and each subchannel number is repli- 
cated for each IID value. 

ID 

Use of Dynamic Switch: 

Referring to Figs. 16A and 16B, a physical 
channel 65 may or may not be connected through 

15 a dynamic switch 82 to a physical CU 60 (where 
plural togical CUs may exist within the physical 
CU). If the channel is connected to switch 62, the 
physical channel path is considered a phystoal 
channel link 63 between the CEO t/0 subsystem 

20 and switch 62; and then a physical control unit link 
61 connected between switch 62 and the physical 
CU. 

If switch 62 is not used, the physical channel 
path Is considered the physical channel link be- 

26 tween the CEC I/O subsystem and the physical CU 
(where plural logical CUs may exist within the 
physical CU). 

Rg. 16B shows dynamic switch 62 connected 
to the physical channel links 63-0 through 63-P of 

30 physical channels 65-0 through 65-P. Control unit 
(CU) ports of switch 62 are connected to physical 
CU links 61-0 through 61 -t which connect to ports 
of a physical CU box 60. Plural logical CUs exists 
within physical CU box 60. each of which is able to 

36 use all the ports of the physical CU box. CU box 80 
connects to physical I/O devices A-E through Y-Z. 
(Rgs. 16A and 16B together show an integrated 
embodiment of the invention having different types 
of control blocks providing various types of IID- 

4o associated Images representing 0&-shared chan- 
nels, devices and logical control units.) 

Logical Control Unit Images (LCUCBs): 

45 A physical control unit (physical CU) is an 

entity generally found in an electronic box. or on 
card(s) and/or chip(s) within a box, to control the 
operation of one or more connected 1/0 devices, 
such as DASD. tape, printer, display, etc. 

so The ESCON I/O Interface architecture provides 
for a plurality of kigical control units (k>gicdl CUs) 
to exist within a physical CU. A logical CU provides 
the functions and has the logical appearance of a 
control unit. When plural logical CUs do not exist 

55 within a physical CU. a single logical CU is said to 
exist In the physteal CU. Logical CUs within a 
physical CU can be of the same general type (e.g. 
for control of DASD) or of different general types 
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(e.g. one for control of DASD» another for control of 
printers, etc). 

Each of the logical CUs within a physical CU 
may use all of the ports which exist for the physical 
CU. A logical CU Is uniquely identified within a 
physical CU by the logical CU address which is 
included in the frame header sent from a channel 
to a logical coritrol unit and in the frame header 
sent from a logical control unit to a channel. 

The information and controls in the I/O sub- 
system related to a logical CU is kept in a LCUCB. 
The I/O subsystem identifies a LCUCB by the use 
of a logical CU identifier (LCUCB number). 

This invention provides a set of logical CU 
images for each logical CU by means of a "sharing 
set" of LCUCBs. The LCUCBs in a sharing set are 
respectively assigned to different IIDs (representing 
different OSs). This enables up to all OSs in a CEC 
to share the same logical CU because Information 
and controls related to the logical CU (such as 
information and controls related to logical paths 
between channel images and the logical CU) are 
maintained separately for each image of the logical 
CU. 

Each LCUCB is a sharing set has the same 
LCUCB numkier and is uniquely identified by the 
combination of a LCUCB number and an IID. Fig. 
13 shows an example an array of LCUCBs. similar 
to the arrays of CHCBs and SCBs/SSCBs shown in 
Figs. 8 and 11. respectively. The LCUCBs In the 
array are arranged by LCUCB number 0-K In the 
vertical direction, and by IID numt)ers 0-N In the 
horizontal direction. 

Fig. 16A also shows sharing sets of of LCUCBs 
67-0(0) - 67-0(N) through 67-K(0) - 67-K(N). in 
which all LCUCBs are in sharing sets (no unshared 
LCUCB is used). In Fig. 16A, each sharing set of 
LCUCBs, e.g. 67-0(O) through 67-0(N), is asso- 
ciated with one or more sharing sets of SSCBs. 
SSCB-A(0) - SSCB-A(N) is one such example of 
these sharing sets of SSCBs, and represents the 
same device 7iA that is connected to the asso- 
ciated logical CU shown in Fig. 16B. 

Structure of an LCUCB: 

Fig. 14 shows the content of each LCUCB 
shown in Rg. 13. The first row in the LCUCB 
contains a LCUCB number field for the number 
assigned to this LCUCB, an IID field for the IID 
assigned to the respective LCUCB, and a logical 
CU address field which identifies the logical CU 
within the physical CU. Each LCUCB is the header 
of a busy queue comprising SSCBs {and/or SCBs) 
curremly enqueued on the busy queue and Is used 
in locating the top and bottom elements in the 
queue. Thus, each LCUCB controls a queue of 
subchannel images currently function pending and 
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delayed because of busy conditions. 

The "V" field indicates if LCUCB is valid. V = 1 

indicates the LCUCB is valid. V = 0 indicates that 

the LCUCB is not valid, 
a The "IID" field contains the IID assigned to the 

associated CU image. 

The ^'logical CU address* field contains the 

logical CU address which identifies the logical CU 

within the physical CU. 
to The "LCUCB number* is the logical CU Iden- 
tifier for the I/O subsystem. 

The "CU busy queue count field" contains the 

current length of the busy queue. The length of the 

queue is determined by the numfc3er of subchannel 
15 images on the associated busy queue that are 

function pending and delayed because of busy 

conditions. 

Top and bottom pointer fields are for contain- 
ing addresses of the top and bottom queue ele- 
20 ments In the CU queue. 

The "summation of queue counts" field adds 
the queue-count field to the summation at the time 
a subchannel image is added to the specified busy 
queue. 

25 The "summation of enqueues" field contains 

an unsigned binary count of the number of times a 
subchannel image is added to the specified busy 
queue. 

CHPlOs 0-7 are the same as the up to eight 
30 CHPIDs in each of the SSCBs for devices asso- 
ciated with the logical CU represented by the re- 
spective LCUCB. 

Following the above defined fields within the 
LCUCB are eight sutsset fields, of which each sub- 
3S set is associated with a different one of the eight 
CHPID fields. Each subset contains the following 
fields: 

Reid B contains a busy indication for ttie asso- 
ciated logical CU Image. 
40 Field E indicates if a request exists for estab- 

lishment of a logical path t>etween the associated 
logical CU image and channel image. 

Retd R indicates if a request exists for the 
removal of a logical path between the associated 
46 logical CU image and channel Image. 

Field S indicates if a request exists for a 
device-level-system-reset between the associated 
logical CU image and channel image. 

Field L indicates if a currently established logi- 
50 cal path exists between the associated logical CU 
image and channel image. 

The "physical channel link address" field, and 
the "physical CU link address" field can have their 
content combined with the contents of the preced- 
es ing IID and logical CU address field to provide the 
identity of the logical path which could exist be- 
tween the associated channel image and logical 
CU Image. 

17 
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A "switch busy count" field contains a count of 
the number of times an initial selection sequence 
for a start or halt function resulted in a switch-busy 
response on the corresponding logical channel 
path. Each switch-busy-count field conresponds 
one-fdr-one, by relative position, with the PIM bits 
of the subchannels associated with the logical CU. 

The "CU busy count" field contains a count of 
the number of times an initial selection sequence 
for a start or halt function resulted in a control-unit- 
busy response on the corresponding logical chan- 
nel path. Each control-unK-busy-count field cor- 
responds one-for-one, by relative position^ with the 
PIM bits of the subchannels associated with the 
logical CU. 

The^success count" field contains a count of 
the number of times an initial selection sequence 
for a start function resulted In the device accepting 
the first command of the channel program on the 
corresponding logical channel path. Each success- 
count field corresponds one-for-one. by relative po- 
sition, with the PIM bits of the subchannels asso- 
ciated with the logical CU. 

Control Unit Logical Path Control Block (CULPCB): 

A logical path must be established between a 
cfiannel and a logical CU before communication to 
an I/O device attached to that logical CU can take 
place. This inventton expands the identification of a 
logical path (LP) to include the IIO corresponding to 
a channel image. Thus, a unique LP needs to be 
established t^etween each image of a channel and 
a k}gicat CU before communication to an I/O device 
attached to that logical CU can take place using 
each of the respective channel images. A single LP 
is uniquely identified by the combination of the 
physical channel link address, physical CU link 
address, IID. and logk»l CU address, with respect 
to either a physical channel or a control unit port. 

The infonmation and controls in an I/O control, 
unit (CU) related to an established LP are kept in a 
"Control Unit Logical Path Control Block" 
(CULPCB). The number of CULPCBs which exist in 
the I/O control unit's storage detenmlnes the maxi- 
mum number of LPs that a CU can have estab- 
lished at any one time. The maximum number of 
CULPCBs which exist in the I/O control unit's stor- 
age is open-ended since it may be a variable 
number. 

When a channel image requests that a LP be 
established between the channel image and a logi- 
cal CU (using the establish-logical-path procedure), 
the CU attempts to locate an available CULPCB 
which can be associated with the specified LP. A 
CULPCB currently associated with any other estab- 
lished LP Is not considered available by the CU. If 
an available CULPCB can be located, the CU may 



respond to ti^e channel image that the LP has been 
established. If an available CULPCB can not be 
located, the CU responds to the chann^ image that 
the LP has not been established. Once a LP is 
5 established, the CULPCB associated with this es- 
tablished LP is no longer available. The CULPCB 
may later become available if the established LP 
which the CULPCB is associated with Is later re- 
moved. 

10 A CULPCB associated with an established LP 
within a CU is identified by the same identifiers that 
identify a LP with respect to a control unit port. 
That Is, a CULPCB Is uniquely identified by the 
combination of a physical channel link address, 

15 physical CO link address. IID, logical CU address, 
and a control unit port identifier (CU port number). 
Once a CUUK^B becomes associated with an es- 
tablished LP, that CULPCB becomes associated 
with the channel image, logical CU, and contrcd unit 

20 port corresponding to the established LP. 

An available CULPCB within a physical CU 
may be conditionally available for the establish- 
ment of a LP depending upon the identity of the 
logical path and/or control unit port For example, a 

26 CULPCB may be restricted for association with a 
LP which is identified by a sut>set of logical CU 
address values which are valid within a physical 
CU. 

Fig. 168 show an example of a physical CU 60 
30 (packaged in a single box) having a plurality of 
togical CUs 60-0 through 60-K. Each logical CU 
may have a different plurality of CULPCBs asso- 
ciated with the logical CU. For example, logical CU 
60-0 has associated with it CULPCBs 60-0(1) 
36 through 60-0(G) and logical CU 60-K has asso- 
ciated with it CULPCBs 60-K(1) through 60-K(H). 

Structure of an LCUCB: 

40 Fig. 4 illustrates an example of the structure of 

^a control unit logical path control block (CULPCB), 
which is provided in the hardware/microcode of a 
physical CU to represent a single LP which is 
established between a channel image and a logk^al 

45 CU. 

In Rg. 4. the first row in the CULPCB contains 
all of the component Identifiers for the CULPCB 
(which are also the component identifiers of the 
associated established LP and k>glcal channel 

50 path). Each of the other rows In the CULPCB 
represents information about an I/O device con- 
nected to the associated logical CU. for example of 
I/O devices 71 A through 71 E connected to logical 
CU 0 (logical CU address - 0) in FIGURE 16B. 

55 The I/O information includes allegiance indicators 
for the I/O device as defined in the S/3S0 Principles 
of Operation (previously cited herein), a PGID 
(assigned for the t/0 device by an OS), and model- 
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dependent control fields tailored to the particular 
logical CU and device. 

The PQID (multiple path group identifier) re- 
ferences a location tn the CU storage that defines a 
set of logical channel paths selectable by the CU, 6 
given LPs are established, when responding to a 
requesting OS on behaH of an I/O device. The 
channel path group Includes logical channel paths 
connecting the same operating system to the plu- 
rality of ports of a CU. and the group is assigned to 
the PGID by an OS. Because this invention pro- 
vides each OS with separate and unique logical 
channel paths to access a shared I/O device using 
shared channels, each OS may group together 
logical channel paths to a device using its own rs 
desired path-group Identifier (PQID). 

Image Reset 

Prior to this invention, a logical resource parti* 20 
tion reset command issued by the hypervisor to 
the I/O subsystem caused a reset of all controls for 
a logical resource partition along with a reset of all 
control units and devices connected via the logical 
paths associated with the logical resource partition. 2S 
The command included a list of I/O subsystem 
resources dedicated to the logical resource parti- 
tion rather than directly specifying the identity of 
the logical resource partition. The control units and 
devices were reset by issuing device-levehsystem- so 
reset commands over onty those established logi- 
cal paths that were associated with the channels 
dedicated to the specified logical resource partition. 

A logical resource partition reset command was 
issued, tor example, whan activating. Inactivating, 3s 
performing a system resets or performing an initial 
program load (iPL) for the logical resource partition. 

With this invention, an 'image reset" command 
issued by the hypervisor to the I/O subsystem 
causes a reset of all controls for a specified IID 40 
along with a reset of all control units and devices 
connected via the logical paths associated with the 
specified IID. The control units and devices are 
reset, as for example when a system reset of a 
logical resource partition Is perfonmed. by issuing 46 
device-level-system-reset commands over only 
those established logical paths that are associated 
with the specified IID. 

Novel to this invention Is that the image reset 
command reinitializes only those controls for so 
shared I/O resources within the I/O subsystem and 
control units which are associated with the speci- 
fied IID. That is. only controls wrthin SSCBs, 
LCUCBs, and CHCBs which are associated wHh 
the specified IID are reinitialized. SSCBs. LCUCBs, 65. 
and CHCBs associated with other IIDs are not 
affected. Additionally, only controls within 
CULPCBs associated with established logical paths 
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over which a device-level-system-reset command 
is received are reinitialized. Other CULPCBs are 
not affected. 

When the hypervisor issues the image reset 
command, an indication is also included which 
specifies whether the target IID is to be placed in 
the activated state or inactivated state at the com- 
pletion of the Image reset command. The hyper- 
visor specifies that the target IID be placed in the 
activated state, for example, when activating, per- 
forming a system reset, or performing an initial 
program load (IPL) for a logical resource partition. 
The hypervisor specifies that the target IID be 
placed in the inactivated state when inactivating a 
logical resource partition. 

An activated IID is available for use by an OS. 
An inactivated IID Is not available for use by any 
OS, although it may later t>e activated for use by 
an OS. 

The configuration control block (CCB) shown In 
FIGURE 9 is used by the I/O sut>system to control 
the current activated/Inactivated state of each IID. 
When an image reset command Is issued to the I/O 
subsystem, the bit corresponding to the target IID 
is set to one when the IID is to be placed in the 
activated state or Is set to zero when the IID Is to 
be placed in the inactivated state. 

An activate/inactivate indication was not includ- 
ed with the logical resource partition reset com- 
mand used prior to tiiis invention. Instead, the I/O 
subsystem assumed that all logical resource parti- 
tions were always activated. 

Novel to this invention is that the 
actWate/inactivate indication included with the im- 
age reset command enables the I/O subsystem to 
remove all established logical paths associated with 
an inactivated IID because the I/O subsystem is 
now given the knowledge of which IIDs are ac- 
tivated and which IIDs are Inactivated. It is impor- 
tant to remove established k>gical paths for an 
inactivated IID so that CULPCBs within ttie storage 
of I/O control units can be made available for the 
establishment of other logical paths. 

When a previously inactivated IID is activated 
via the image reset command, the I/O subsystem 
attempts to establish all logical paths associated 
with the target IID. When a previously activated IID 
is Inactivated via the image reset command, the I/O 
subsystem removes all togical paths associated 
with the target IID. When a previously activated IID 
is activated via the image reset command, the I/O 
subsystem sends device-level-system-reset com- 
mands over all established logical paths associated 
with tiie target IID in order to reinitialized controls 
within control unit's CULPCBs associated vwth the 
established logical paths. 

The image reset command is part of both the 
Service Call Logical Processor <SCLP) instruction 
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and Processor ControHer CAll (PCCALL) instruction 
which passes a control biock containing the target 
ilD and activate/inactivate indication. This com- 
mand is issued only by the hypervisor. 

5 

i/O Instructions; 

Most of the I/O instructions to the i/O sub- 
system use the SSCBs, CHCBs, LCUCBs, and 
CULPCBs. 10 

Start Sut>channel Instruction Example: 

An example of an I/O instruction is shown in 
Rgs. 17 and 18, which provide a flow diagram of is 
the execution of the S/390 "start subchannel" 
(SSCH) instruction. The SSCH instruction is issued 
by any operating system (OS) in the CEC in Fig. 1 
executing in any resource partition and assigned an 
II D. The steps in the SSCH instnjction execution 20 
are as follows: 

101) Before an OS can use the Invention on a 
CEC, a state description (SD) for the OS (shown 
In FIGURE 6) is loaded into the memory of the 
CEC by the CEC hypervisor. The content of the 26 
SD defines resources for partition J and is as- 
signed an IlD value. 

102} Step 102 loada the OS into the CEC mem- 
ory assigned to resource partition J. 
.103) The OS is dispatched on a CPU in the so 

CEC by the hypervisor. 

104) The OS dispatches an application program 
as a task on the dispatched CPU. 

105) The task requests an I/O operation of the 

OS by the task issuing an supervisor call (SVC) 36 
instruction, using application-to-OS program in- 
terface faciiities such as a read, get, write, or put 
request 

106) The OS issues an SSCH instruction to start 

the I/O device to perform a requested operation. 40 

107) CPU microcode responds to the SSCH 
instruction operation code by accessing the 110 
from the SD of the issuing OS and by obtaining 
the requested subchannel number from general 
register GRi. Then the microcode uses the IlD 45 
and subchannel numt}er to select a required 
SSCB In Fig. 12. This SSCB Is the subchannel 
image used for the OS to access the desired i/O 
device. 

108) The microcode tests the validity (V) bit and so 
I/O interpretation control bit (INCB) in the SSCB 

to determine if it is a valid SSCB and whether it 
is operating in passthru mode, respectively. If 
the SSCB is valid and operating In passtfiru 
mode, the yes exit is taken to step 115. ff the ss 
SSCB is not valid or is not operating in passthru 
mode, the no exit is taken to step 1 09. 
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109) Using the subchannel number from general 
register GRI and an IID = 0 (i.e, the hypen^isor's 
IlD). a second attempt is made to select a SSCB 
Cm FIGURE 12) whteh represents the desired I/O 
device. The microcode tests the validity (V) bit 
and I/O niterpretation control bit (INCB) in the 
SSCB to determine if it is a valid SSCB and 
whether it is operating in passtiiru mode, re- 
spectively. If the SSCB is valid and operating in 
passthru mode, the yes exit is taken to step 1 15 
(i.e. the hypervisor has setup the SSCB as- 
signed to itself such that it can t>e used by an 
OS in passthru mode). If the SSCB Is not valid 
or is not operating in passthru mode, the no extX 
is taken to Step 113. 

113) The hypervisor intercepts the execution of 
the SIE instruction for OS-J. The hypervisor may 
either terminate the I/O instruction with an un- 
successful condition code (CC) (e.g. when the 
selected SSCB is invalkl) or may simulate the 
execution of the I/O instruction for OS-J (e.g. 
when the selected SSCB Is not operating in 
passthru mode). 

115) The CPU microcode accesses SSCB for 
OS-J to execute the synchronous portion of the 
SSCH instructicn. 

116) This step tests the SSCH Instruction's con- 
dition code to detenmine if the CPU part of the 
SSCH instruction execution executed success- 
fully, which involves the CPU microcode select- 
ing an I/O processor (lOP); Using the information 
contained in ti)e SSCB, the CPU performs the 
normal checks to determine which condition 
code (CC) to give to the SSCH instruction. If an 
unsuccessful CC is determined, step 117 is en- 
tered. If successful, step 118 is entered. 

117) If the SSCH instruction's CC indicates the 
CPU did not execute it successfully, an excep- 
tion is indicated which causes step 118 to tie 
entered. 

118) The hypervisor intercepts to determine why 
the CPU did not execute the SSCH instruction 
successfully, and takes action accordingly. 

119) Then, the CPU enqueues the SSCB on the 
selected lOP's work queue contained in the I/O 
subsystem storage, and ends the CPU portion 
of the instnjction. When the CPU executed the 
synchronous portion of the SSCH instruction 
successfully, an asyrichronous portion of Its ex- 
ecution begins with lOP operations on the vrark 
queue. 

120) The work queue operates Flf=0. An lOP 
dequeues the SSCB from the work queue when 
the SSCB rises to the top of the queue. Then, 
the lOP performs path selection by selecting a 
channel processor represented by one of the 
CHPIDs In the SSCB being used. 
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121) Once a channel processor Is selected, the 
lOP issues a comnr^and to the channel processor 
to begin its I/O operations. The lOP command 
contains the IID of the SSCB, the CHPID, and 

the subchannel number in the SSCB, Then, step 6 
131 in Rg. 16 Is entered. 131) Channel proces- 
sor receives the lOP command and calculates 
the address of the SSCB using the received 
subchannel number and IID. 

122) Channel processor constructs an ESCON to 
command frame to send to the director (when 

one exists) and to the control unit FIGURE 5 
Illustrates the frame header, which Includes the 
address information. The header Includes the 
fields shown in FIGURE 5. The LP identifiers are fs 
obtained from a LCUCB. The LCUCB associated 
with the SSCB ia located using the LCUCB 
number and HO in the SSCB. 

123) The channel processor transmits the frame 
through the director (when one exists) to the 20 
addressed logical control unit 

124) The CU receives the frame, examines tt, 
and accesses the I/O device addressed in the 
frame. The logical CU maintains its controls for 

the I/O operation in the CULPCB which is lo- 29 
cated using the identifiers in the frame header 
and the control unit port identifier over which the 
frame was received. (The combination of the 
source link address and source logical address 
identify the channel image which sent the frame. so 
The combination of the destination link address 
and destination logical address identify the logi- 
cal control unit which is the target of the frame. 
The device address identifies the particular I/O 
device on the logical control unit) Any request- as 
ed data Is accessed by the addressed I/O de- 
vice. The CU then sends a command accep- 
tance frame to the channel, using the frame- 
sending procedure described below. In the pre- 
ferred embodiment, the ESCON protocol Is used 40 
to transfer the data associated with the com- 
mand frame, if a write request, data transmitted 
in subsequent frames is written by the device. If 
a read request, data read by the device is sent 
back to the CU for placement in return frames 4s 
the CU will send to the channel processor. 
126) In order to send a frame to the channel 
processor, the CU constructs a returning ES- 
CON frame to send to the channel, which has a 
frame header similar to that in Rg. 5, except the 50 
content of the destination , and source parts of 
the frame header are reversed. (The source link 
address in the frame is set to the physical CU 
link address. The source togical address is set 
to the logical CU address. The destination link 55 
address Is set to the physical channel link ad- 
dress. The destination togical address is set to 
the IID value. The frame also contains the t/0 
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device's corresponding device address.) 

127) The channel processor receives the frame 
and examines it. The combination of the des- 
tination link address and destination logical ad- 
dress identify the OS-J channel Image which is 
the target of the frame. The combination of the 
source link address and source logk^ address 
identify the logical control unit which sent the 
frame. The device address identifies the particu- 
lar I/O device on the logical control unit. 

128) Using the destination logical address (IID). 
source link address (physical CU link address), 
source logical address (logteal CU address), and 
device address from the frame, the channel pro- 
cessor computes the address of the SSCB using 
a reverse tookup control block (RLCB). If the 
frame is a data franrw. the data are stored in the 
program buffer. If the frame is a status frame, 
the channel processor places ending status In 
that SSCB. 

129) After the status frame Is received, the 

channel processor signals the lOP that the I/O 
operation is completed for this command, in- 
dicating the subchannel number and IID of the 
SSCB. 

130) The lOP calculates the address of the 
SSCB using the subchannel number and the IID 
and places the SSCB on the bottom of an in- 
terruption queue for the Interruption subclass 
Indicated in a field off the SSCB. The interruption 
queue Is contained in the I/O subsystem. This 
ends the lOP operations for the SSCH instruc- 
tion. The inten^ption queue uses a FIFO struc- 
ture. An interniption signal is sent to all CPUs in 
the CEC that the imerruption Is pending in an 
interruption queue. 

131) The first CPU which is enabled for the I/O 
interrupt dequeues the SSCB from the interrup- 
tion queue and constructs an intanruption re- 
sponse block (IRB) In the system storage for 
OS-J when the I/O interruption takes place. The 
IRB contains the subchannel number but does 
not contain the IID. 

Reset Channel Path Instruction: 

Another example novel to this invention Is the 
-reset channel path" (RCHP) instruction, which pri- 
or to this invemion reset all controls for the speci- 
fied channel aK>ng with all control units and devices 
connected via the logical paths associated with the 
specified channel. With this invention, this instruc- 
tion requires a specified IID and resets only those 
controls and logical paths associated with the chart- 
nel image identified by the IID and CHPID. 

When an OS issues the "reset channel path" 
instruction, the target channel (CHPID) is specified 
in GPR 1. This instruction is not executed Inter- 
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pretively via the SIE Instruction, but Is intercepted 
by the hypervisor which in turn provides the II D 
assigned to the channel image in QPR 1 in addition 
to the CHPID before issuing the RCHP instruction 
to the I/O 8ubsysten>. Fig. 19 shows the format of 
GPR1 provided by this invention. The combination 
of the IID and CHPID values specify the channel 
image as the target of the reset function. 

The I/O subsystem resets controls for the 
specified channel image and issues devtee-level- 
system-reset commands only for those established 
logical paths that are associated with the specified 
channel image by building frame headers that in- 
clude the specified IID. All other channel images 
and all other established logical paths are not af- 
fected. Further, the I/O subsystem resets the con* 
trots (busy indicatkins and allegiances) in only 
those subchannel images (SSCBs) associated with 
the specified channel image. Controls in subchan- 
nel images (SSCBs) associated with any other 
channel images are not affected. 

Channel Reports: 

Certain channel reports are presented to an OS 
to report information about either a channel or a 
subchannel. A channel report consist of one or 
more chanrwl report words (CRWs) chained to- 
gether. Prior to this invention, these channel re- 
ports were presented to a single OS since the 
channels and subchannels were not shared. With 
this invention a mechanism is provided to present 
these chanrwl reports either to a single OS or to 
multiple OSs when sharing subchannels and chan- 
nels. In soma cases the channel report applies only 
to one of the OSs sharing the channel or subchan- 
nel, in other cases, the channel report must be 
presented to all OSs sharing the channel or sub- 
channel. 

Rg. 20 shows the fbrmat of the channel report 
vyord as provided by this invention. 

When the channel report applies to all OSs. the 
I/O subsystem presents the report to the hypervisor 
in the same way as was done prior to this inven- 
tion. The Image (I) bit in the channel report word is 
set to zero. Novel to this invention, the hypervisor 
in turn presents this report to all of the OSs sharing 
the channel or 8ut>channet. An example of this type 
of report is a permanent failure in the channel 
hardware. 

When the channel report applies to only one 
OS. this invention provides a means for the I/O 
subsystem to pass the llD assigned to the image 
for which the report is Intended along with the 
report. The Image (I) bit is set to one. Further the 
Chaining (C) bit is also set to one and an additional 
channel report word is chained to the original which 
provides the IID value in the Reporting-Source ID 
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field. The hypervisor in turn presents this report 
only to the OS associated with the IID without the 
chained CRW containing the IID and without the 1 
bit being set to one. An example of this report 
s could be the result of a RCHP instruction issued by 
ftie same OS. 

Channel Reconfiguration: 

w Prior to this invention, a channel configuration 
command issued by an OS or by manual means 
caused the system to physically vary the target 
channel offline or online. A channel that Is varied 
online to an OS is available for use by that OS. A 

15 channel that is varied offline is not available to any 
OS. 

With this invention, a channel configuration 
command issued by an OS causes the I/O channel 
subsystem to vary ofnine/online only the channel 

20 image associated with the OS. The channel con- 
figuration commands are part of the Service Call 
Logical Processor (SCLP) instruction which passes 
a control block containing the target channel. This 
instruction is not executed interpretively via the SIE 

26 instruction, but is intercepted by the hypervisor. 
The hypervisor in turn provides the IID assigned to 
the image in the control blocic in addition to the 
CHPID before issuing the channel configuration 
command to the I/O subsystem. The combination 

30 of the IID and CHPID values specify the channel 
image as the target of the configure command. 

The I/O subsystem resets controls for the 
specified channel image and either removes logical 
paths (for vary offline) or establishes logical paths 

3fi (for vary online) only for those logical paths that are 
associated with the specified channel image by 
building frame headers that include the specified 
IID. All other channel images and all other estate 
lished logical paths are not affected. Further, the 

40 I/O subsystem resets the controls (busy indications 
and allegiances) and either turns off the appropriate 
path availability bit <fbr vary offline) or turns on the 
appropriate path availat»lity bit (for vary online) in 
only those subchannel images (SSCBs) associated 

45 with the specified channel Image. Controls In sub- 
channel images (SSCBs) associated with any other 
channel images are not affected. 

Many variations and modifications are shown 
which do not depart from the scope and spirit of 

50 the invention and will now become apparent to 
those of ekilt in the art. Thus, it should be under- 
stood that the at>ove described embodiments have 
been provided by way of example rather than as a 
limitation. 

55 
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Claims 

1. A method of sharing I/O resources by a plural- 
ity of programs, comprising the steps of: 

storing a plurality of image Identifiers (IIDs) in s 
one or more resource idervtifying control blocks 
In a computer electronic complex (CEC) and 
associating the IIDs with categories of pro- 
grams executable on the CEC; 
structuring a set of I/O control blocks (CBs) for to 
an I/O resource by associating each CB in the 
set with a different IID in a plurality of IIDs. and 
locating the set of CBs In an l/O-control stor- 
age of a computer electronic complex (CEC); 
and '5 
obtaining an IID associated with a category of 
programs requiring the use of an I/O resource, 
and accessing the set for the I/O resource and 
accessing the CB in the set associated with 
the obtained IID, storing states of the I/O re- so 
source in the accessed CB for the using pro- 
gram, sharing of the 1/0 resource being ob- 
tained among executing programs in the dif- 
ferent categories requiring the I/O resource by 
means of the different CBs in the set providing 2S 
separata images of the resource to each of the 
executing programs. 

2. A method of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 . compris- so 
ing the steps of: 

providing a single operating system (OS) in the 
CEC with multiple categories of programs in 
which each category has one or more IIDs, 
and associating an IID with each executing 3b 
program in each category; 
utilizing an klentrfier of the I/O resource to 
select a required set of CBs and utilizing an 110 
associated with the program to select a re- 
quired CB in the required set to enable in- 40 
dependent use of the 1/0 resource by pro- 
grams In the different categories using dif- 
ferent CBs in the set of CBs. 

a A method of sharing I/O resources by a plural- 45 
ity of programs as defined in Claim 1 , compris- 
ing the steps of: 

providing multiple operating systems (OSs) in 
the CEC in vthtch each OS has one category, 
and each category has one or more IIDs, and so 
associating an IID with each executing program 
in each category: 

utilizing an identifier of the I/O resource to 
select a required set of CBs and utilizing an IID 
associated with the program to select a re- 65 
quired CB in the required set to enable in- 
dependent use of the I/O resource by pro- 
grams in the different OSs using different CBs 
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in the set of CBs. 

4. A method of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 , compris- 
ing the steps of: 

accessing the IIDs and CBs by means of Inter- 
nal code which is not accessible to the execut- 
ing programs. 

5. A method of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 , compris- 
ing the steps of: 

accessing the IIDs by means of system soft- 
ware used by a CEC hypervisor, and acces- 
sing the CBs by means of internal code, in 
which the IIDs and CBs are not accessible to 
any programs executing in the CEC. 

6. A n^ethod of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 , compris- 
ing the steps of: 

providing plural categories of programs in 
whk:h a hypervisor is one of the categories. 

7. A method of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 , compris- 
ing the steps of: 

providing plural categories of programs in 
which operating systems (OSs) are one or 
more of the categories. 

& A method of sharing I/O resources by a plural- 
ity of programs as defined in claim 1 , compris- 
ing the steps of: 

communicating an I/O request directly from 
one of the programs to an I/O subsystem using 
at least one shared I/O resource without hyper- 
visor intervention; 

performing by the I/O subsystem of the I/O 
request using the shared I/O resource without 
hypervisor Intervention; and 
responding to the requesting program without 
hypervisor intervention. 

9. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs), comprising the 
steps of: 

storing an image kJenttfier <IID) in a resource 
kJentifying control btock (SD) for each of plural 
OSs operating In a computer electronic com- 
plex (CEC): 

structuring within an l/ONControi storage for the 
CEC of a set of 1/0 control blocks (CBS) for 
each of plural 1/0 resources of the CEC, and 
associating each CB in the set with a different 
IID; and 

accessing a required CB by an I/O processor 
for an I/O operation by selecting a set of CBs 
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with an identifier of an I/O resource and by 
selecting a required CB in a selected set with 
the 110 stored in the SD of an OS requesting 
the I/O operation, and sharing the I/O resource 
among the OSs associated with the HQs of the 
different OBs in the set. 

10. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
Claim 9. further comprising the steps of: 
associating one of the IID values with a hyper- 
visor of the CEO (instead of with any OS) to 
enable the hypervlsor to have Its respective 
image of the I/O resource to permit the hyper- 
visor to use the I/O resource independently of 
any OS and concurrently with the OSs. 

11. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
Claim 9, further comprising the steps of: 
structuring within an 1/Ocontrol storage for the 
CEC of a single I/O control block (CB) for any 
1/0 resource and associating the CB with a 
hypervisor IID or an OS IID to provide a single 
image for an unshared I/O resource only to the 
hypetvisor or OS, respectively, for enabling the 
hypervisor or OS, respectively, to control the 
unshared VO resource in order to intermix CEC 
I/O operations for shared resources and for 
unshared resources, for which the OSs directly 
use shared resources without hypervisor Inter- 
vention, and for which the hypervisor or the 
OSs can directly use unshared resources. 

1Z A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
Claim 9, further comprising the steps of: 
concurrently executing programs in the dif- 
ferent OSs in a CEC with the programs re- 
questing I/O operations requiring a same I/O 
resource connectable to the CEC; 
selecting a required set of CBs for the I/O 
resource, and a different CB in the set being 
accessed by each of tiie different OSs requir- 
ing the same I/O resource; and 
setting states independentiy in the different 
CBs for the cor^urrently executing programs 
of the different OSs to enable independent 
control for the different programs over the I/O 
resource being shared by the OSs. 

ia A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
claim 12, further comprising the steps of: 
communicating a representation of the IID of 
each I/O operation from the CEC to an I/O 
control unit (as the I/O resource for the I/O 
operation), aruj storing the representation of 
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tiie IID by ti^e I/O control unit to enable the I/O 
control unit to respond to tiie OS for the I/O 
request. 

5 14. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
daim 12, further comprising the steps of: 
responding by the I/O control unit to the CEC 
for the I/O operation by the I/O control unit 

10 accessing the representation of tiie ilD stored 
for the I/O operation and signalling the repre- 
sentation of the IID to an i/0 subsystem in the 
CEC; 

selecting by the I/O subsystem of a required 
IS set of CBs for the 1/0 resource, and selecting a 

required CB in the set for the OS requesting 
tiie t/O operation with the I/O control unit; and 
queuing the required CB into an interruption 
queue for the OS requesting the I/O operation 
20 to enable a CPU executing the OS to handle 

the I/O interruption without any access to the 
IID to Isolate tiie OSs from the tiDs and pro- 
vide security of IIDs from the OSs. 

26 16. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
Claim 9, further comprising the step of: 
resetting the state of an Image of an I/O re- 
source for an OS (represented by a CB of the 

30 1/0 resource associated with a requested IID in 

the CEC) without affecting the state of any 
other CB for the same I/O resource or the state 
of any CB associated with any other I/O re- 
source by accessing and setting to an initial 

36 state only the CB of the IID and resource 

identified to be reset. 

16. A metiiod of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
40 Claim 9, further comprising the step of: 

resetting the state of CBs for all I/O resources 
(represented by all CBs of the I/O resources 
associated with a requested IID in the CEC) 
witiiout affecting tiie state of I/O resources 

49 associated with any ottier IID by searching 
through the CBs of the CEC and setting to an 
initial state the CBs for all I/O resources found 
for the requested IID. 

50 17. A method of sharing I/O resources by a plural- 

ity of operating systems (OSs) as defined in 
claim 9. further comprising the step of: 
structuring within an l/0<ontrol storage for tiie 
CEC of a sharing set of I/O control blocks 
65 (CHCBs) for each of a pfurality of physical I/O 

channels (each p)hysical I/O channel being the 
I/O resource for a set of CHCBs) and as- 
sociating each CHCB in the set with a different 

24 
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IID to provide a different image of the physical 
I/O charinel to each of the OSs for enabling 
Independent control over each physical 1/0 
channel by the OSs sharing the physical chan* 
nel. 

ia A method of sharing physical I/O channels and 
I/O devices among a plurality of operating sys- 
tems (OSs) as defined in Claim 17. further 

comprising the steps of: 
identifying in each CHCB of an offline/online 
field, and setting the offline/online field inde- 
pendently in each of the CHCBs in the sharing 
set to enable each of the OSs to independently 
control whether an associated image of the 
physical channel (provided by an associated 
CIHCB) is online or offKne. 

19. A method of sharing i/O resources by a plural- 
ity of operating systems (OSs) as defined in 
claim 17. further comprising the step of: 
specifying a channel path identifier (CHPID) as 
an identifier of each physical channel, and the 
physical channel being the 1/0 resource for a 
sharing set of CBs. 

20. A method of sharing I/O resources by a plural* 
ity of operating systems (OSs) as defined in 
claim 17, further comprising the step off: 
structuring within an l/0*control storage for the 
CEC of a single VO control block (CB) for any 
physical I/O channel (the channel being the I/O 
resource for the single CB) and associating the 
CB with a hypervisor IID or an OS IID to 
provide a single image for an unshared phys- 
ical channel only to the hypervisor or the OS, 
respectively, for enabling only the hypervisor 
or the OS, respectively, to control each un- 
shared physical channel in order to intenmix 
shared channels and unshared channels In a 
CEC for enabling any of the plurality of OSs to 
use shared channels without hypervisor inter- 
vention, and for which the hypen/isor or the 
OSs can directly use unshared channels. 

21. A method of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 
claim 9. further comprising the steps of: 
structuring within an l/O-control storage for the 
CEC of a set of I/O control blocks (CBs) for 
each of a plurslity of subchannels in which 
each subchannel represents an I/O device (the 
subchannel being the I/O resource for tiie set 
of CBs), using an Identifier of the sutxrhannel 
as an identifier of the set of CBs. and as- 
sociating each CB in the set with a different IID 
to provide a different image of each sut>chan- 
nel to each of the OSs for enabling indepen- 



dent control over each 1/0 device by each of 
the OSs. 

22. A method of sharing I/O resources by a plurai- 

6 ity of operating systems (OSs) as defined in 

Claim 21, further comprising tiie step of: 
structuring within an l/OKX>ntrol storage for the 
CEC of a single I/O control block (CB) for any 
subchannel (an I/O device identified by the 

to subchannel being the I/O resource for the sin- 
gle CB) and associating the CB with a hyper- 
visor IID or OS IID to provide a single image 
for an unshared subchannel only to the hyper- 
visor or an OS for enabling only the hypervisor 

15 or 0S» respectively, to control each unshared 

subchannel in order to intermix shared sub- 
channels and unshared subchannels in a CEC 
for enat>llng any of the plurality of OSs to use 
shared I/O devices without hypervisor interven- 

20 tion, and for which the hypervisor or the OSs 

can directly use unshared I/O devices. 

2a A nnethod of sharing I/O resources by a plural- 
ity of operating systems (OSs) as defined in 

2$ claim 9. further comprising the steps of: 

stmcturing within an l/O-control storage for the 
CEC of a set of I/O control blocks (CBs) for 
each image of a I/O control unit (CU) connec- 
table to the CEC (as one of the I/O resources) 

30 and associating each CB In the set with a 
different IID to provide a different image to the 
respective OSs of the CU for enak>ting in- 
dependent control over the CU by each of the 
OSs. 

35 

24. A n^ethod of efficientiy sharing I/O channels. 
I/O control units, and I/O devices by a plurality 
of operating systems (OSs). comprising the 
steps of: 

40 storing in processor storage one or more spe- 

cial control bk>cks (SDs) for containing OS 
identifiers (llDs) fbr use in I/O resource sharing 
operations of a computer electronic complex 

(CEC); 

45 Storing in I/O storage of a sharing set of sub- 

channel control blocks (SSCBs) for each sub- 
channel (for a shared I/O device) for which 
each SSCB in the set is associated with a 
different IID for accessing the device, staring in 

50 the I/O storage of a sharing set of channel 

control blocks (CHCBs) for the same 1/0 chan- 
nel (shared channel) in which each CHCB in 
tiie set is associated with a different IID. and 
storing in the t'O storage of a sharing set of 

S6 logical control unit conti-ol blocks (LCUCBs) for 

each logical I/O control unit in which each 
LCUCB in the set is associated with a different 
IID; and 
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controlling an I/O operation for a requesting OS 
by obtaining an I ID associated with the OS and 
selecting an SSCB with the IID in a sharing set 
for a required subchannel I/O resource and 
selecting a LCUCB with the IID in a sharing set s 
for a required control unit I/O resource and 
selecting a CHCB with the IID in a sharing set 
for a required channel I/O resource tbr en- 
abling the OS to share the required I/O chan- 
nel and the required I/O control unit and the 10 
required I/O device with at least one other OS 
operating in the GEO. 

25. A method of sharing I/O channels and I/O 
devices among a plurality of operating systems rs 
(OSs) as defined in Claim 24, further compris- 
ing the steps of: 

generating by the CEO for the requesting OS 
of a frame header containing a specified logi- 
cal path from the CEC through the required 20 
channel to a control unit associated with a 
device specified In the required subchannel, 
the logical path comprising: a representation of 
the IID of the requesting OS, an address for 
the required channel, an address associated 2& 
with a required control unit (CU); 
transmitting the generated frame header to the 
CU using the available logical path; and 
storing in a CU storage of the logical path for 
use by the CU in later responding to the re- so 
questing OS regarding the I/O operation. 

26. A method of sharing VO channels arK) I/O 
devices among a plurality of operating systems 
(OSs) as defined in Claim 25, further compris- ss 
ing the steps of: 

also storing in the CU storage of a group of 
addresses for logical paths associated with 
each of plural IIDs for the OSs in a CEC 
making I/O requests to the CU. and assigning 40 
a path group identifier <PGID) in the CU stor- 
age for each group of logical paths for each 
OS in the CEC with which the CU can commu- 
nicate; 

recognizing by the CU of a need to provide a 45 
response to an OS for an I/O request made to 
the CU by the OS, and accessing by the CU of 
the PGID for the OS to access the group of 
logical paths for the OS in the CU storage: 
selecting in the CU storage of an available 50 
logical path in the accessed group of logical 
paths for the accessed PGID; 
generating by the CU of a responding frame 
header containing the available logical path for 
the accessed PGID containing a representation ss 
of an IID of the OS to receive the response; 
transmitting the responding frame header to 
the CEC using the available logical path; and 



selecting in the receiving CEC of a sharing set 
of SSCBs for the subchannel of the device 
having an address in the responding frame, 
and selecting of an SSCB in the sharing set 
with the representation of the IID in the logical 
path in the responding frame header. 

27. A method of sharing I/O channels and I/O 
devices among a plurality of operating systems 
(OSs) as defined in Claim 26. further compris- 
ing the steps of: 

identifying in each SSCB of an interruption 
queue to t>e used by the SSCB of multiple 
subclass interruption queues provided in the 
CEC; and 

choosing for the queuing step of the subclass 
inten^uption queue identified in the selected 
SSCB. 



2& A method of sharing I/O resources among a 
plurality of operating systems (OSs) as defined 
in Claim 9, further comprising the steps of: 
communicating by an I/O subsystem to a 
hypervisor of an occurrence of a special con- 
dition in the I/O subsystem, the communication 
including an IID and an identification of each 
resource affected by the special condition and 
an Indication that a report about the special 
condition is to be forwarded to the OS as- 
signed the IID; and 

fbnfvardtng by the hypervisor of the report con- 
taining information atx)ut the special condition 
to the OS. 

29. A method of sharing I/O resources among a 
plurality of operating systems (OSs) as defined 
in Claim 9, further comprising the steps of: 
communicating by an I/O subsystem to a 
hypervisor of an occurrence of a special con- 
dition in the I/O subsystem, the communication 
including an identification of each resource af- 
fected by the special condition and an indica- 
tion that a report about the special condition is 
to be forwarded to each OS sharing the I/O ' 
resource; and 

forwarding by the hypervisor of the report con- 
taining information about the special condition 
to each OS sharing the I/O resource. 

30. A method of sharing I/O resources among a 
plurality of operating systems (OSs) as defined 
in Claim 9. further comprising the steps of: 
activating a logical resource partitton (LPAR) In 
the CEC for use by an OS with an image-reset 
command; 

communicating to the I/O subsystem that the 
LPAR Is to t>e activated; and 
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establishing representations of logical paths 
(LPs) in the I/O subsystem and affected I/O 
control units for the LPAR being activated. 

31* A method of sharing I/O resources among a s 
plurality of operating systems (OSs) as defined 
in Claim 9» further comprising Itie steps of: 
inactivating a logical resource partition (LPAR) 
in the GEO with an image-reset command; 
communicating to the I/O subsystem the IID of to 
the LPAR with an indication the LPAR is being 
inactivated; and 

removing representations of logical paths (LPs) 
from the I/O subsystem and from affected 1/0 
control units fOr the LPAR being inactivated. ts 
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